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Avant-propos 


Le present ouvrage s’adresse a tous ceux qui ont a participer a la gestion de projet 
dans le domaine des systemes d’information, aussi bien du cote « metier » que du 
cote logiciel. 

II vise a presenter et a illustrer a travers de nombreux exercices et cas prati- 
ques, souvent inspires de cas reels, l’etat de Part des techniques utilisables. Mais 
ces techniques ne sont pas des elements independants et banalises d’une boite a 
outils du manager de projet. Elies prennent leur sens et leur utilite par rapport 
a des problemes ou difficultes surgissant dans la pratique. C’est pourquoi ce livre 
est organise en suivant un cycle general de preoccupations rencontrees, d’une 
maniere ou d’une autre, sur tout projet : decouper, estimer les charges, planifier, 
prendre en compte les risques, reconnaitre la dimension humaine, integrer les 
principes de la qualite... Pour chaque aspect, les techniques seront mises en 
regard d’un probleme dans une situation donnee. 

Cependant, la presentation normalisee du cadre du management de projet 
s’inscrit aujourd’hui dans une approche par processus qui eclaire de fagon quasi- 
independante les differentes dimensions a gerer. Des activites d’integration 
visent a en assurer la coherence. Pour faciliter la comprehension et l’apprentissage, 
nous avons toutefois privilegie une logique sequentielle a derouler de fagon 
cyclique : planification - suivi - pilotage, jusqu’a la cloture du projet. En effet, 
certaines techniques peuvent concemer plusieurs aspects : nous situerons leur 
finalite globale. Par exemple, les techniques d’estimation des charges sont utili- 
sees aussi bien pour le management des delais que pour le management des couts. 
C’est pourquoi, l’ordre de presentation est cale sur l’ordre habituel de la premiere 
utilisation de la technique dans un cycle projet, les aspects qualite ayant ete 
places en dernier : decoupage, estimation des charges, planification, aspects 
humains, analyse et controle des risques et pilotage. 
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Cependant, nous avons etabli un lien clair avec le cadre par processus. Nous 
proposons notamment une aide a la certification en management de projet du 
PMI, qui s’inscrit dans cette perspective processus. Le lecteur qui vise un tel 
objectif trouvera dans cet ouvrage, non seulement des apports concrets et 
nuances sur la fagon de mener un projet systeme d’ information, mais pourra 
situer ces connaissances dans un referentiel structure en processus. Dans cette 
6 e edition, nous avons introduit pour chaque aspect du management de projet 
une perspective particuliere sur les methodes agiles. 
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Introduction 


Conduire un projet de conception et de developpement d’un systeme d’informa- 
tion est une operation complexe. Si tout projet comporte une part d’ incertitude, 
la nature d’un systeme d’information en accroit les risques. En grande partie 
immateriel, un systeme d’information met en jeu des acteurs multiples et entre en 
interaction avec l’organisation de l’entreprise. L’ analyse des difficultes rencon- 
trees dans la pratique montre le besoin d’un management de projet solide. La 
maitrise des delais, des couts et de la qualite passe par la mise en oeuvre de tech- 
niques, de principes et de dispositifs specifiques a ce type de projet. 

Le but du present ouvrage, qui prend en compte les normes recentes, est d’offrir 
une vue complete des differents aspects du management de projet centree sur les 
projets systeme d’information. II foumit un support pour analyser les situations 
et decider des options a prendre. II s’adresse aussi bien a des etudiants qu’a des 
praticiens. Le point de vue privilegie est celui du chef de projet. 

Depassant le cadre d’une methode de conception (axee sur le « comment 
faire ? ») ou de conduite (centree sur un decoupage particulier en etapes), ce livre 
offre un ensemble d’instruments utilisables quelle que soit la methode retenue. 
II a ete congu avec un objectif operationnel et inclut de nombreux exemples et 
exercices resolus. II couvre le cycle complet, de revaluation des risques a la capi- 
talisation d’experience, et il integre les preoccupations concemant la dimension 
humaine d’un projet, la gestion du changement et la qualite. La lecture de cet 
ouvrage peut etre faite de deux manieres : 

• soit en deroulant les differents aspects, qui sont presentes dans l’ordre ou, 
generalement, ils apparaissent dans un projet ; 

• soit en se reportant directement a l’un ou l’autre chapitre selon la techni- 
que recherchee. 

La premiere partie decrit les principes et techniques, et foumit un eclairage 
particulier sur les methodes agiles ; la deuxieme partie propose des exercices 
et etudes de cas illustrant la theorie, et presente une utilisation pratique d’un 
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progiciel de planification et suivi ; la troisieme partie est consacree aux referen- 
tiels et a la certification PMI. 


PREMIERE PARTIE 


PRINCIPES 
ET TECHNIQUES 


Apres une introduction au management des projets systeme d’ information qui 
se termine par une rapide presentation des methodes agiles, l’ouvrage aborde les 
principes et les modeles de decoupage. Les techniques d’estimation des charges 
sont presentees au chapitre 3. La planification et la prise en compte de la dimen- 
sion humaine d’un projet font l’objet des deux chapitres suivants. Le chapitre 6 
traite de Paralyse des risques et de leur controle. Le chapitre 7 decrit les concepts 
du pilotage et les techniques pour suivre et maitriser un projet. La premiere 
partie s’acheve sur un panorama des differents aspects de la problematique 
qualite. 
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Problcmatiquc 
du management de projet 


1.1 ORIGINE ET EVOLUTION DU MANAGEMENT DE PROJET 

C’est au debut des annees 1950 que sont nees les premieres reflexions publiques 
sur la conduite d’un projet, principalement dans les pays anglo-saxons. Elies sont 
liees aux grands projets engages dans divers domaines industriels : aeronautique, 
travaux publics, armement. L’objectif etait de developper des techniques et des 
methodes pour augmenter la maitrise des travaux et la coordination des diffe- 
rents corps de metier. Historiquement, ce developpement s’est inscrit dans le 
courant de la recherche operationnelle, qui visait une formalisation mathemati- 
que des problemes de gestion pour prendre les decisions optimales. II a corres- 
pondu egalement au grand mouvement de planification mis en oeuvre dans la 
plupart des pays developpes et qui a influence certaines theories manageriales. 

Le corpus methodologique sur la conduite de projet s’est ensuite constitue en 
grande partie par la pratique. Les societes de services et de conseil, ainsi que de 
nombreux consultants independants, ont developpe une offre variee de pres ra- 
tions qui comprennent la direction d’un projet ; 1’ assistance au chef projet sur 
certains aspects, tels que la planification et la surveillance des delais ou des 
couts, la gestion de la qualite du projet, la gestion administrative du projet. . . ; le 
conseil ponctuel pour certaines taches telles que le decoupage et l’organisation 
du projet ou l’estimation des charges. 

Depuis une trentaine d’annees, des associations professionnelles ont oeuvre 
pour faire reconnaitre le role et les competences particulieres des chefs de projet. 
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Leurs actions ont conduit a une diffusion et une reconnaissance des certifications 
en management de projet, qui valident l’acquisition de savoirs et savoir-faire 
specifiques. Citons notamment l’AFITEP (Association francophone de manage- 
ment de projet), 1’IPMA ( International Project Management Association ) d’origine 
europeenne et le PMI ( Project Management Institute) d’origine nord-americaine. 
En Grande-Bretagne, les pouvoirs publics ont joue un role majeur dans la defini- 
tion d’une methode, PRINCE2, qui donne egalement lieu a une certification. 
Une breve presentation en est donnee au chapitre 16. La troisieme partie de cet 
ouvrage foumit des elements complementaires sur differents referentiels et sur 
les certifications. 

En ce qui conceme les techniques, la planification a occupe pendant long- 
temps une place centrale dans la conduite d’un projet. Certaines fonctions speci- 
fiques de planificateur ont existe jusqu’a recemment. On a aujourd’hui une 
vision plus large du role du chef de projet. Par ailleurs, l’origine industrielle a 
fortement marque le decoupage d’un projet ; dans le domaine des systemes 
d’information, il a fallu des annees pour que d’autres approches apparaissent. 

Nous allons maintenant voir comment est defini un projet et quelles sont les 
activites qui relevent du management de projet. 

1.2 DEFINITIONS D’UN PROJET 

1.2.1 L’approche generate 

La langue franchise a attache au mot projet des degres de precision divers. Le 
terme represente d’abord une intention, souvent floue, dont la realisation peut 
etre lointaine ; c’est par exemple le cas lorsque l’on evoque un projet de voyage. 
Une seconde definition le decrit comme une etude preparatoire, parfois exhaus- 
tive, qui va etre soumise a decision : on parle ainsi d’un projet de loi ou d’un 
projet d’urbanisme. 

Quelle que soit l’acception retenue, le projet precede une realisation ou un etat 
definitif. C’est une image plus ou moins precise d’un futur que l’on pense atteindre. 

Dans cet ouvrage, nous utilisons le mot projet dans un sens oriente vers le 
management de projet. Les gestionnaires ont ramene ce vocable dans le present 
en le reliant a des actions a accomplir. 

Un projet est defini comme un ensemble d’activites a effectuer pour atteindre 
un but defini de fagon specifique. De fagon plus precise, on parle de « travail en 
mode projet » lorsque Ton doit atteindre un objectif avec des moyens ad hoc et 
dans un delai donne. Le mode projet requiert une organisation et un manage- 
ment adaptes. On le represente parfois sous forme d’un triangle (figure 1.1), ce 
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qui exprime la contrainte de solidarity entre les sommets : si l’un des sommets 
bouge et que l’on veut conserver le meme triangle, il faut agir sur l’un ou les deux 
autres sommets. Ainsi, toute evolution du perimetre du projet aura des conse- 
quences soit sur le delai, soit sur les ressources a mettre en oeuvre. Un alea modi- 
fiant la disponibilite des ressources se repercutera soit sur le delai, soit sur 
l’objectif vise. 


Objectif 



Moyens Delai 

Figure 1.1 — Le triangle Projet. 

Le mode Projet se distingue de celui d’une activite repetitive ou d’une 
mission permanente. 

Une activite repetitive est la reponse a une occurrence d’evenement declen- 
cheur prealablement identifie dans l’entreprise. On peut definir une procedure 
stable pour decrire les activites a accomplir. Ainsi un acheteur dans un service 
Approvisionnement declenche la procedure Commande chaque fois qu’un 
besoin d’ achat se manifeste. A l’inverse, le lancement d’un projet releve d’une 
decision. Tout projet est unique et ne peut etre traite par un dispositif standard. 
II necessite une prise en compte de ses caracteristiques propres. 

De son cote, une mission permanente est definie par un but, mais sans mention 
de delai ; elle subsiste jusqu’a une decision de reorganisation. Ainsi, une mission 
Qualite dans l’entreprise doit mettre en oeuvre un ensemble d’activites pour 
surveiller et augmenter la qualite : definir des criteres qualite, identifier les 
mesures a effectuer, traiter les ecarts... Le responsable de la mission ne peut en 
prononcer la suppression. Tout projet est, au contraire, temporaire : par nature, il 
est destine a s’achever a un horizon visible. Les ressources sont affectees pour une 
duree limitee. C’est aux responsables du projet qu’il revient de declarer celui-ci 
termine. 

Le mode Projet introduit du mouvement dans un dispositif organisationnel 
stable. Cela provient de ce que l’on entreprend quelque chose de nouveau. 
L’effet est renforce par les affectations temporaires des acteurs. Cette instability 
souvent dynamisante est parfois recherchee pour des activites traditionnelle- 
ment effectuees dans de missions globales. C’est ce que l’on appelle « la gestion 
par projet ». Des activites diverses sont ainsi menees comme des projets, dans le 
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sens ou l’on formalise precisement l’objectif a atteindre et on y affecte des 
moyens provisoires. Par exemple, un demenagement, [’elaboration d’un docu- 
ment commercial ou la reorganisation du reseau de distribution peuvent etre 
geres comme des projets. 

1.2.2 Les definitions normalisees 

Nous avons retenu trois des principales definitions normalisees : celle de 1’ISO, 
organisation intemationale de normalisation, celle du PMI et celle conjointe de 
PAFITEP et l’AFNOR, association frangaise de normalisation. 

Selon IS010006 : 2003 1 , un projet est un « processus unique, qui consiste en 
un ensemble d’activites coordonnees et maitrisees comportant des dates de debut 
et de fin, entrepris dans le but d’ atteindre un objectif conforme a des exigences 
specifiques telles que les contraintes de delais, de couts et de ressources ». 

L’unicite du processus projet doit etre comprise de deux fagons. D’une part, la 
sequence des activites qui permettront d’ atteindre l’objectif doit etre definie de 
fagon adaptee a chaque projet, meme si Ton reutilise des trames generales. 
D’ autre part, les activites qui composent le projet seront executees une seule fois. 
II y a done unicite au niveau du type et au niveau de l’instance. 

Le referentiel du PMI, appele Guide du PMBOK ( Project Management Body of 
Knowledge), donne d’un projet la definition suivante : 

« entreprise temporaire decidee pour obtenir un produit ou un service uni- 
que ». 

L’unicite du produit entrainera celle des activites a mettre en oeuvre. 

L’AFITEP et l’AFNOR definissent un projet comme un « ensemble d’ actions 
a realiser pour satisfaire un objectif defini, dans le cadre d’une mission precise, et 
pour la realisation desquelles on a identifie non seulement un debut, mais aussi 
une fin » [AFITEP, 2000]. 

Une distinction est introduite entre les projets d’ingenierie qui visent l’obtention 
d’un resultat pour un client, et les projets produit debouchant sur un modele qui 
fera ensuite l’objet d’une fabrication repetitive. Les projets de systeme d’information 
relevent exclusivement de la premiere categorie. 

Chacune de ces trois definitions met 1’ accent sur des activites finalisees et 
soumises a contraintes, nous y retrouvons les trois elements du triangle Projet : 
objectif, moyens, delai. 

1 . Le contenu de cette norme, intitulee « Systemes de management de la qualite. Lignes direc- 
trices pour le management de la qualite dans les projets » est expose au chapitre 16 . 
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13 QU’EST-CE QUE LE MANAGEMENT DE PROJET ? 

1.3.1 L’approche generate du management de projet 

Le management de projet a pour but de mener un projet a son terme en organisant 
et en surveillant son deroulement. 

Le champ du management de projet est cale sur les caracteristiques generiques 
d’un projet. Les trois aspects representes par le triangle Projet doivent etre mis sous 
controle. Chacun fait l’objet d’un management specifique, qui prend en compte 
l’existence des deux autres ; chaque sommet du triangle Projet en genere un autre, 
le tout formant un nouveau triangle, celui du management de projet. Ainsi : 

• Le delai donne lieu a un management du temps dont le role est de definir le 
parcours et de le jalonner, d’etablir des calendriers et de maitriser la 
consommation de l’enveloppe temps. 

• Les moyens affectes constituent le budget du projet, qui est transforme en 
travail, locaux, materiel, temps machine, deplacement... Cette transfor- 
mation necessite un management des ressources portant sur les ressources 
humaines et les moyens materiels. Dans les projets systeme d’information, 
les ressources humaines occupent une place primordiale. Utiliser chacun 
au mieux, constituer des equipes efficaces, affecter les personnes au 
moment adequat en fonction de leurs competences, coordonner les 
travaux, limiter le nombre d’acteurs sans pour autant exclure... telles sont 
les attributions de cette fonction. 

• L’objectif du projet doit a son terme etre concretise par une ou plusieurs 
foumitures. Ce sommet donne naissance au management de la production, 
qui a pour but de suivre et diriger l’avancement vers l’objectif tout au long 
du projet. On parle parfois de « faire converger le projet » : cela signifie 
qu’il faut sans cesse s’assurer que l’on se rapproche du but et que Ton ne 
part pas dans des directions remettant en cause un avancement consolide. 

Ces trois aspects sont representes par le triangle du management de projet 
donne a la figure 1.2. 

Management de la production 
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La solidarity des sommets est permanent®. 

On veut parfois marquer une priority pour ly parametre tymporel : on parly 
alors d’un « management par les delais ». II faut toutefois se garder de l’isoler des 
deux autres, sous peine de conduire le projet a l’echec. 

De fagon analogue, manager des ressources et une production en dehors de 
toute contrainte temporelle est une erreur : la prise en compte d’echeances stimule 
la production et facilite la gestion des ressources. 

Ces trois preoccupations sont toujours presen tes dans les differentes taches de 
management de projet, dont nous allons maintenant examiner le contenu et 
l’articulation. 

En se referant a la description classique d’une fonction managerial, on peut 
decomposer l’activite de management de projet en trois activites principales autour 
de la production proprement dite (figure 1.3). 



Figure 1.3 — Les activites du management de projet. 

• Analyser : il s’agit de determiner le chemin que Ton va emprunter pour 
avancer vers l’objectif. Pour cela, on etudie les caracteristiques du projet, 
son contexte, les risques qui le menacent et l’etat de son avancement. 
Cela conduit a un decoupage du projet en activites a entreprendre et a une 
estimation de l’effort necessaire. La maille de cette analyse varie selon le 
moment du projet auquel on se place. 

• Organiser : on repere les contraintes d’enchainement entre les taches afin 
de les ordonnancer. Cela permet d’etablir un calendrier. L’ organisation 
recouvre aussi la constitution d’une equipe, c’est-a-dire des personnes qui 
sont affectees et imputees au projet, en determinant les bons profils. Les 
relations avec tous les partenaires necessaires sont egalement prises en 
compte. Des que la charge est importante, on repartit le travail entre 
plusieurs personnes, voire plusieurs equipes, ce qui conduit a mettre en 
place des moyens de partage d’informations pour eviter les incoherences. 
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• Piloter : cette activite comprend le suivi de l’avancement du projet, en 
quantite et en qualite, ainsi que l’analyse et le traitement des ecarts avec 
ce qui etait prevu, les orientations et les decisions a prendre ou a faire 
prendre. Le pilotage inclut egalement le management de l’equipe et la 
gestion des conflits. 

Nous n’avons pas isole une activite specifique concernant la qualite. En effet, 
nous considerons qu’elle intervient transversalement dans toute la gestion de 
projet et qu’elle doit etre integree aux trois activites principales : analyser, 
organiser, piloter. Pour des raisons de clarte, nous avons cependant dans cet ouvrage 
rassemble ces preoccupations dans un chapitre a part. 

La presentation des activites de management de projet donne parfois l’impression 
d’une repartition inegale dans le temps, la fonction s’exergant principalement en 
debut de projet et la production prenant ensuite le relais. Cette vision est tout a 
fait fausse. 

Un projet est manage du debut a la fin. C’est ce que represente la boucle de 
retroaction de la figure 1.3, qui doit etre lue de fagon dynamique : selon les aleas 
et le stade d’avancement, on accentue plutot l’une ou 1’ autre activite, en adaptant 
le contenu. 

Par exemple, en debut de projet, 1’ activite Analyser comporte une analyse de 
risque qui permet notamment de choisir un type d’approche : selon le degre 
de visibility de l’objectif initial, on choisit soit de faire une etude prealable, soit 
d’elaborer directement des specifications, soit de construire un prototype. 

Un alea, interne ou exteme, au cours du deroulement du projet peut conduire 
a une replanification, une nouvelle repartition des taches, ou meme une modifi- 
cation de l’objectif. Prenons l’exemple d’un projet de planification de la produc- 
tion dans une entreprise fabriquant des equipements d’automobile. Supposons 
que l’entreprise soit rachetee par un constructed, il faut alors integrer les previ- 
sions de fabrication du constructed lui-meme, ce qui represente une fonction 
supplementaire. 

Par ailleurs, si le projet est important, l’equipe constitute au debut du projet 
se renforce et se structure differemment selon les etapes d’avancement. 

Les principes et techniques lies aux trois grandes activites du management de 
projet sont traites dans les differents chapitres. 

L’ activite Analyser est traitee dans le chapitre 2 (decoupage d’un projet), le 
chapitre 3 (estimation des charges) et le chapitre 6 (analyse des risques). 
L’ aspect qualite de cette tache figure au paragraphe du chapitre 8 (maitrise de la 
qualite) traitant des facteurs et indicateurs. 
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L’activite Organiser est decrite dans les chapitres 4 (techniques de planta- 
tion) et 5 (organisation du travail). La qualite specifique a l’organisation du 
projet est traitee dans le paragraphe consacre au plan qualite. 

L’activite Piloter fait l’objet du chapitre 7 (pilotage du projet), du paragraphe 
traitant du controle des risques au chapitre 6, du paragraphe concemant le role du 
chef de projet au chapitre 5 et du paragraphe sur le controle qualite au chapitre 8. 


1.3.2 La definition normalisee du management de projet 

Le referentiel de 1’IPMA [IPMA, 1999] donne une definition generale de l’ensemble 
des activites de management de projet : « Le management de projet consiste a 
planifier, organiser, suivre et maitriser tous les aspects d’un projet, ainsi que la 
motivation de tous ceux qui sont impliques dans le projet, de fagon a atteindre les 
objectifs de fagon sure et dans les criteres definis de couts, delais et performance. 
Cela inclut les taches de direction necessaries aux performances du projet. » 

L’AFITEP et l’AFNOR [AFITEP, 2000] s’attachent a distinguer plusieurs 
termes de signification proche, afin d’identifier plusieurs roles dans le manage- 
ment d’un projet. 

Le management est defini comme « V ensemble des taches permettant de conduire 
une operation quelconque a bonne fin ». Associe a projet, ce terme est decrit par les 
taches qu’il recouvre : le management de projet comprend « les taches de direc- 
tion, gestion, maitrise, pilotage ». Ces taches peuvent etre assurees « par une meme 
personne ou plusieurs, appartenant & une meme entreprise ou a plusieurs entites, 
parties prenantes du projet ». 

Le management de projet est done de la responsabilite du chef de projet, 
meme s’il s’appuie parfois sur un ou plusieurs assistant pour certaines activites. 
Le management de projet se compose done de quatre activites, pouvant corres- 
pondre a une fonction : 

• Direction de projet. 

• Gestion de projet. 

• Maitrise. 

• Pilotage. 

La direction de projet, qui est toujours exercee par le chef de projet, a pour 
mission essentielle de : 

1. Fixer les objectifs, la strategic et les moyens (e’est-a-dire l’itineraire et 
l’horaire, les etapes et les ressources qu’on doit y trouver). 

2. Coordonner les actions successives et/ou concomitantes. 
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3. Maitriser, c’est-a-dire etre a tout instant capable, dans tous les domaines, 
de modifier l’itineraire et l’horaire (done les etapes et les ressources) si un 
objectif evolue, si l’itineraire (et/ou l’horaire) ne peut etre respecte, si une 
etape doit etre grillee, et modifier les etapes suivantes en consequence. 

4. Optimiser la repartition des ressources (en main-d’oeuvre, materiel, etc.) en 
vue d’arriver a une solution optimale, ou de moindre cout, pour l’ensemble 
du projet. 

Pour accomplir la mission de direction de projet, le chef de projet a besoin 
d’ analyser les risques, d’estimer la charge, d’organiser le travail, de le planifier, de 
le suivre. Pour cela, il doit effectuer, ou faire effectuer, un ensemble de taches 
relevant de la gestion de projet, e’est-a-dire : « l’ ensemble des taches de preparation des 
referentiels, de controle de leur respect, d’ analyse des causes de deviation, et de reporting. » 

II est precise que : « la gestion de projet a pour objectif essentiel d’apporter a la 
direction de projet [...] des elements pour prendre en temps voulu toutes les decisions 
lui permettant de respecter les termes du contrat passe avec le client, en contenu, en 
qualite, en delai et en couts (depenses et recettes) ». Cette activite comprend egalement 
la capitalisation d’experience. 

L’ activite de maitrise correspond a des taches qui ont ete extraites de la gestion 
de projet et sont centrees sur une preoccupation : par exemple, la maitrise de la 
qualite ou la maitrise des couts. Les decisions relevent toujours de 1’ activite de 
direction de projet. 

L’ activite de pilotage, lorsqu’elle est isolee de la fonction de direction de 
projet, est limitee a l’activite periodique d’orientation du projet par un Comite 
de pilotage, dont le role est evoque au chapitre 5. 

En conclusion, on peut retenir deux aspects majeurs du management de 
projet : decider et gerer. Dans cet ouvrage, le terme de pilotage sera utilise dans 
le sens cybernetique donne au chapitre 7, e’est-a-dire relevant du chef de projet 
dans son activite de direction de projet. 

14 LE MANAGEMENT DES PROJETS SYSTEME D’INFORMATION 

1 A. 1 Caracteristiques d’un projet systeme d’information 

II convient tout d’abord de rappeler la definition d’un systeme d’information, 
qui met en lumiere son caractere complexe. En effet, dans la mesure ou e’est un 
« ensemble organise de ressources : materiel, logiciel, personnel, donnees, proce- 
dures... permettant d’acquerir, de traiter, stocker, communiquer des informations 
(sous formes donnees, textes, images, sons...) dans des organisations. » [Reix, 
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2004], il va falloir prendre en compte des dimensions diverses. De plus, son 
caractere immateriel augmente la difficult^ quand on veut en obtenir une 
description precise. Cela n’est pas sans consequence sur les projets. 

Le triplet {objectif, moyens, delai} presente, dans le domaine systeme d’informa- 
tion, trois caracteristiques specifiques, a savoir : 

1 . II y a interaction entre l’ objectif d’une part et les moyens/delais d’ autre part. 
Une premiere identification de l’objectif conduit a evaluer la charge 
globale du projet. Cela permet de decider d’une echeance cible theorique 
et des moyens a affecter. Si d’autres contraintes obligent a limiter le delai 
ou le budget, on ajuste l’objectif, selon le principe du design-to-cost 
(conception contrainte par le budget disponible). Apres decision, on va 
considerer comme fixes les deux parametres « moyens » et « delai » initia- 
lement alloues et on evaluera l’efficience du projet — composante de son 
succes — par rapport a ces valeurs. 

2. L’objectif du projet n’est parfaitement defini qua V achievement du projet. Un 
systeme d’information n’est pas un objet materiel, dont on peut donner 
une representation visuelle. Un logiciel est quelque chose d’abstrait. II est 
done decrit par ses fonctions ; cependant, une description exhaustive est 
longue et couteuse. Les modeles n’en donnent qu’une vue partielle. La 
maquette qu’on peut en faire est une analogie, non une miniature. De 
meme un prototype n’est pas, comme en milieu industriel, ce qui precede 
la serie. Cette indetermination est absente des projets industriels qui ont 
servi de reference a certaines des techniques, notamment le decoupage du 
projet. De plus, les modeles de processus metiers representant les modifi- 
cations apportees sont egalement abstraits et ne rendent pas en compte du 
vecu des acteurs qui s’exprime progressivement. 

3. Le developpement d’un systeme d’information ne se deroule pas dans un vide 
organisationnel, mais dans une organisation, dont les particularites font 
partie de la caracterisation du projet lui-meme. 

Les comportements des acteurs sont influences par le systeme d’organisation 
dans lequel ils agissent. Celui-ci comprend a la fois la repartition du pouvoir 
et des ressources, la division des activites, les modes de coordination, les 
procedures operatoires, les statuts... Les relations personnelles sont regies 
par un ensemble de normes, fondees sur les valeurs dominantes de l’entre- 
prise, qui contraignent, legitiment ou limitent Taction. Les acteurs ne 
forment pas un groupe uni vers la realisation d’un meme objectif. Dans les 
zones d’ incertitude se developpent les strategies des groupes ou des individus. 

Si le pouvoir est un enjeu dans tout systeme d’organisation, e’est Tefficacite 
que Ton invoque le plus souvent lors des choix de conception (rapidite, cout...) 
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d’un systeme d’information. La demarche d’elaboration est generalement guidee par 
une rationalite d’optimisation, faisant abstraction d’autres formes de rationalite. 
Le processus de developpement d’un systeme d’information est certes un processus 
rationnel, mais qui se double souvent d’un processus politique et d’un processus psycho - 
logique. Leur prise en compte permet d’ analyser certaines reactions ou certains 
conflits, voire de les eviter. 


1 A. 2 Les objecti fs des projets systemes d’information 

II est parfois utile de distinguer systeme d’information et systeme informatique 
(figure 1.4) : 

• Le systeme d’information est la partie du reel constitute d’informations 
organisees, d’evenements ayant un effet sur ces informations et d’acteurs 
qui agissent sur ces informations ou a partir de ces informations, selon des 
processus visant une finalite de gestion et utilisant les technologies de 
l’information. 

• Un systeme informatique est un ensemble organise d’objets techniques — 
materiels, logiciels, applications — dont la mise en oeuvre realise 1’ infra- 
structure d’un systeme d’information. 



Figure 1.4 — Systeme d’information 
et systeme informatique. 
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Dans cette perspective, meme si un projet systeme d’information inclut un 
developpement ou un parametrage de logiciel, les objectifs du projet sont claire- 
ment ceux qui sont attaches au systeme d’information. En effet, c’est l’utilisation 
que Ton va faire du logiciel — l’aide apportee aux processus et les informations 
gerees — qui va apporter de la valeur a l’entreprise. 

La reflexion sur les objectifs des projets s’inscrit done aujourd’hui dans la 
perspective de l’alignement strategique, selon laquelle la mission du systeme 
d’information est d’aider l’entreprise a atteindre ses objectifs. Tout projet systeme 
d’information est done toujours un projet de l’entreprise. Cela implique que les 
acteurs metiers, que Ton appelle « maitrise d’ouvrage », decident des evolutions 
du systeme d’information. Mais egalement que les orientations strategiques 
soient etre traduites en objectifs du systeme d’information, ce qui fait partie des 
premieres e tapes du projet. 

Par exemple, diminuer les couts de gestion peut se traduire par installer un 
systeme de workflow ou mettre en place un suivi de la qualite des fournisseurs. 
L’objectif strategique d’ameliorer l’efficacite des promotions peut conduire a 
developper un systeme d’analyse d’effets ou bien un systeme de suivi des promo- 
tions des concurrents (intelligence economique). 

Augmenter les ventes peut passer par la mise en place d’un site de vente en 
ligne ou la conception d’une application d’aide a la vente pour les commerciaux. 

Comprendre les objectifs du projet et faire emerger des reponses adequates est 
de la responsabilite du chef de projet. On rencontre souvent les grandes categories 
suivantes, qui auront des consequences sur le management du projet. Nous allons 
les esquisser : 

• Productivity administrative : la rentabilite du capital investi est recherchee 
dans la diminution de main d’oeuvre grace a l’automatisation d’une partie 
des taches. Le climat social sera tendu et la gestion du changement diffi- 
cile a mener. La participation des utilisateurs peut conduire a un blocage 
du projet. 

• Aide au management : l’objectif majeur du projet est l’amelioration des prises 
de decision au moyen d’un observatoire au service du management. On va 
batir une memoire de l’organisation et de ce qui l’entoure, a partir de laquelle 
on pourra construire des tableaux de bord, faire des analyses, assurer une 
veille concurrentielle. La conception du systeme doit etre tres proche des 
gestionnaires, faute de quoi le systeme ne sera guere utilise. 

• Efficacite operationnelle : on attend un meilleur fonctionnement operationnel 
par un usage creatif des technologies de l’information et de la communication. 
L’analyse et la reconstruction des processus sont determinantes, mais la 
gestion du changement est un enjeu essentiel. 
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• Evolutivite : on cherche a obtenir un systeme flexible pouvant etre modifie 
rapidement en cas devolution des contraintes et/ou de la strategic et 
sachant prendre en compte des adaptations ou des personnalisations non 
encore identifies au moment du projet. Cet objectif s’inscrit dans une 
meilleure maitrise des investissements informatiques. La comprehension 
du domaine et de son evolution est importante. 

• Utilisation d’une nouvelle technologie : le but principal du projet est d’expe- 
rimenter une nouvelle technologie, pour voir ce que l’on peut en tirer ou 
pour obtenir un « effet vitrine » vis-a-vis de l’exterieur. Un delai court est 
un element essentiel de la reussite du projet. 


1.4.3 La complexite d’un projet systeme d’information 

Un projet systeme d’information est souvent qualifie de « complexe », dans 
la mesure ou il comporte de nombreux elements qui sont interdependants. La 
complexite des projets a fait l’objet d’un effort de clarification il y a quelques 
annees 1 . 

Certains distinguent la complexite organisationnelle et la complexite techno- 
logique. 

La premiere renvoie notamment a la multiplicite des niveaux hierarchiques 
et des entites impliquees, ainsi qu’au degre eleve de la division du travail, induit 
par la diversite des competences requises. Dans un projet complexe, les elements 
organisationnels ne sont pas independants et ils doivent etre coordonnes. 

La complexite technologique, a une maille plus fine, recouvre la variete des 
taches identifies, ainsi que celle des entrees et des sorties du projet. Si le projet 
est complexe, les taches sont interdependantes, de meme que les technologies 
mises en oeuvre et les equipes intervenant dans le projet. Cette forme de 
complexite augmente lorsque le delai du projet est reduit, car un nombre accru 
de taches doivent alors etre executees en parallele. 

En general, la complexite du projet decoule de la complexite du systeme a 
realiser, et plus particulierement de la structure visee, c’est-a-dire le nombre et la 
variete de fonctions, et leurs imbrications. C’est pourquoi on appelle parfois cet 
ensemble — complexite organisationnelle et complexite technologique — la 
complexite structurale du projet. La difficult^ generee par cette complexite est 
liee au fait que tout changement ou option prise dans un sous-systeme peut avoir 
non seulement des repercussions sur d’autres sous-systemes, mais aussi des 
retroactions sur d’autres parties du sous-systeme lui-meme. Pour les projets 

1. Voir par exemple « The need for new paradigms for complex project », T. M. Williams, Inter- 
national Journal of Project Management , 17, 5, pp. 269-273, 1999. 
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systeme d’information, la complexite est accrue par le caractere abstrait du logi- 
del et la difficult^ a tester tous les cas de figure pour en eliminer les dysfonction- 
nements. C’est egalement le cas lorsque Ton met en place un progiciel integre 
avec un haut degre de parametrage, dont on ne prevoit pas toutes les consequen- 
ces organisationnelles. 

D’autres auteurs ont ajoute a la complexite structural une forme de 
complexite liee a V incertitude du projet. Cette incertitude peut peser sur les buts 
du projet et sur les methodes a employer. 

Les projets systeme d’information sont, pour une partie d’entre eux, de bons 
exemples de projets aux buts incertains. En effet, les exigences des clients/utilisa- 
teurs sont difficiles a center. Elies sont souvent multiples, voire contradictoires, et 
surtout elles peuvent varier au cours du temps, entrainant des modifications et 
retours en arriere, dont les impacts ne sont pas toujours faciles a reperer. D’ou 
une complexite accrue dans le management du projet. 

Si les methodes pertinentes pour le projet ne sont pas perceptibles pour 
l’equipe de management de projet, par exemple dans le cas de nouveaute techno- 
logique, la planification du projet sera difficile et donnera lieu a de nombreux 
ajustements. 

Nous approfondirons l’etude des sources de complexite dans le chapitre 6 
consacre a la maitrise des risques du projet. 

Nous allons terminer ce chapitre consacre a la problematique du manage- 
ment de projet en presentant rapidement des approches d’organisation du projet 
qui se sont progressivement developpees depuis une quinzaine d’ annees pour 
prendre en compte l’instabilite des besoins et des specifications des projets systeme 
d’information : les methodes agiles. 


1.5 MANAGEMENT DE PROJET ET METHODES AGILES 

A partir des annees 1970, les grandes entreprises ont commence a rencontrer de 
serieux problemes de qualite et de productivity dans le developpement de leurs 
applications informatiques. Pour augmenter la rigueur du processus projet et 
ameliorer les relations entre les informaticiens et leurs clients/utilisateurs, diffe- 
rentes methodes ont ete proposees, d’abord dans les annees 1980 celles qui ont 
ete appelees « structures » (SA/SD, SADT, JSD, SSADM, Merise...), puis 
dans les annees 1990 celles dites « orientees objet » (OOD, OMT, OOSE, UML). 
Elies offraient, en general, un cadre guidant le deroulement du projet et une aide 
a la representation du futur systeme d’information. 
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Ces methodes, adoptees a des degres divers par les entreprises, ont en general 
permis d’ organiser le travail du service informatique en introduisant une culture 
methodologique. Cependant, dans le cadre de chaque projet il est necessaire de 
passer d’une methode theorique a une methode pratique 1 , ce qui n’a pas toujours 
ete pergu. La mise en pratique des methodes a done souvent donne lieu a un 
dispositif rigide et contraignant pour les projets, alors que les problemes de delais 
et de qualite continuent a se poser. D’ou l’emergence d’un courant mettant 
l’accent sur la souplesse. 

Les methodes dites « agiles » ont officiellement regu leur nom en 2001 suite a 
une rencontre entre 17 auteurs de methodes defendant une organisation des 
projets de developpement logiciel moins structuree et plus legere que les metho- 
des en vigueur, qui ont cosigne un Manifeste Agile 2 . L’agilite des methodes fait 
reference a la capacite qu’elles sont censees donner pour contoumer les obstacles 
et s’adapter aux particularites de chaque projet. L’agilite est largement de nature 
humaine et organisationnelle. 

Donnons quelques reperes sur les principales methodes pouvant etre inscrites 
sous le label « agile » — RAD, DSDM, XP, SCRUM et Crystal — qui ont 
toutes ete elaborees au cours des annees 1990. 

• RAD 

Cette methode est la plus ancienne de toutes celles qui peuvent etre quali- 
fies d’ agiles. Elle a ete proposee par James Martin 3 en 1991 pour promou- 
voir une utilisation efficace des outils de developpement rapide et de 
prototypage. En effet, la diffusion de tels outils n’avait eu qu’un faible 
impact sur la longueur des projets. L’idee centrale de RAD, Rapid Applied - 
tion Development (developpement rapide d’application), est que seule 
l’introduction des utilisateurs/decideurs dans l’equipe de projet permet a la 
fois d’ameliorer la satisfaction et de raccourcir la duree du processus projet. 
Alors que les methodes structurees etaient focalisees sur les regies de 
decoupage et les techniques de modelisation, J. Martin soutient que la 
dimension organisationnelle des projets est l’element cle pour le succes 
d’un projet systeme d’information. II propose done des principes et techniques 
d’organisation et de pilotage du projet, visant a reduire fortement les delais 
tout en assurant la qualite du produit. 


1. Voir pour plus de details : C. Morley, « Choisir une methode de developpement de systeme 
d’information: probleme technique ou probleme de management », Colloque Information et 
Management, AIM, Grenoble, octobre 1991. 

2. Manifesto for Agile Software Development, http://agilemanifesto.org/ 

3. James Martin, Rapid Application Development, Macmillan Publishing Company, 1991. 
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• DSDM 

L’apparition de RAD a suscite un vaste mouvement chez les editeurs 
d’outils de developpement qui se sont assigne une marque « RAD » a des 
fins commerciales. On a ainsi observe des pratiques de developpement, 
portees par un certain nombre de consultants ou societes de conseil en 
informatique, fort eloignees des principes de la methode, mais qui revendi- 
quaient le label RAD. Cela a conduit, en 1994, une quinzaine d’entreprises 
industrielles en Grande- Bretagne, utilisatrices de RAD, a s’associer en consor- 
tium pour diffuser un cadre de reference normalisant les pratiques RAD. 
C’est ainsi qu’est nee la methode DSDM, Dynamic System Development 
Method, avec un premier ouvrage en 1997 1 , ecrit par la directrice technique 
du consortium. 

• XP 

XP, eXtreme Programming est la methode agile la plus connue, probable- 
ment en raison du nombre d’auteurs qui ont contribue a son elaboration. 
L’experience initiale etait un projet visant a remplacer plusieurs applica- 
tions de paye dans le groupe Chrysler par une application unique. En 
1996, un an apres son demarrage, alors qu’il pietinait, ce projet fut place 
sous la responsabilite de Ken Beck. Celui-ci a convaincu la Direction 
informatique de repartir a zero et, avec l’aide de Ron Jeffries, experimenta 
des approches nouvelles d’organisation de l’equipe et de mobilisation des 
utilisateurs. Ils s’etaient engages sur un delai de livraison d’une premiere 
version un an plus tard, ce qui representait un defi par rapport aux estima- 
tions initiales et aux difficulties rencontrees. Le delai fut globalement 
respecte, mais l’entreprise Chrysler ayant ete rachetee en 1998 par 
Daimler, le projet fut definitivement arrete debut 2000. Ce demi-succes 
n’empecha pas la formalisation de pratiques qui avaient introduit des 
changements profonds dans le rythme et les modalites de deroulement du 
projet. De nombreux debats ont eu lieu avec d’autres acteurs methodolo- 
giques, notamment avec Ward Cunningham, inventeur du wiki et inter- 
locuteur de longue date de K. Beck, notamment sur les pratiques de 
developpement. Le nom fut officiellement donne en 1999, lors de la publi- 
cation des premiers ouvrages 2 . Le terme « extreme » fut choisi pour 
evoquer une approche radicalement differente, basee sur la systematisa- 
tion de pratiques considerees comme efficaces, en les poussant jusqu’a 
leurs limites. Le terme « programming » rappelle le contexte d’application 
de la methode, celui des developpeurs. La dimension publique des echanges 


1. Jennifer Stapleton, Dynamic System Development Method, Addison-Wesley, 1997. 

2. K. Beck, Extreme Programming Explained, Addison-Wesley, 1999 ; R. Jeffries, A. Anderson et 
C. Hendrickson, Extreme Programming Installed, Addison-Wesley, 2000. 
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autour de XP a contribue a sa diffusion et a conduit d’autres auteurs a se 
rallier au courant XP. 

• SCRUM 

La methode SCRUM a ete elaboree vers 1993 par differents auteurs 
influences par les travaux sur l’innovation de H. Takeuchi and I. Nonaka 1 . 
Ces chercheurs avaient enquete dans plusieurs entreprises industrielles 
(Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, and 
Hewlett-Packard) et ils ont mis en avant que le processus d’innovation ne 
peut pas etre soumis a une planification, compte tenu de nombre 
d’elements imprevisibles. Plus precisement, certaines parties du processus 
peuvent etre planifiees, mais d’autres doivent etre considerees comme des 
boites noires, non connaissables a priori. Dans ce cas, le role joue par 
l’equipe de projet, sa motivation, sa capacite d’autonomie et de collabora- 
tion sont essentiels pour le succes de projet. 

Ken Schwaber et Jeff Sutherland, les plus actifs dans la formalisation 
autour de SCRUM, considerent qu’un projet systeme d’information 
comporte egalement des parties previsibles et d’autres non, et ils preconi- 
sent un mode de management du projet prenant en compte ces deux 
aspects. Le terme Scrum, utilise par Takeuchi et Nonaka, est emprunte au 
vocabulaire du rugby, la « melee ». Une melee est une phase qui rassemble 
de fagon etroite et ordonnee l’ensemble des joueurs, et qui permet de 
reprendre le jeu rapidement, en toute securite et equitablement, apres une 
faute mineure ou un arret de jeu. Ce terme a ete adopte comme nom de la 
methode d’une part pour mettre l’accent sur la tension entre moments 
forts de rapprochement et trajectoires plus individuelles, d’autre part pour 
souligner la necessite de faire regulierement des reunions rapides d’equipe 
visant a continuellement ramener le projet sur une bonne trajectoire. 
Differents ouvrages sont parus a partir de 2001 2 . 

• Crystal 

En 1991, IBM a charge un consultant, Alistair Cockbum, d’elaborer une 
methode pour le developpement d’ application dans un environnement 
oriente-objet. Apres avoir observe de nombreux projets, Cockbum a 
conclu que la dimension communication etait centrale pour la reussite de 
ces projets 3 . II a ete egalement sensible a la diversite des situations 
de projet, et la necessite d’une adaptation a chaque type de situation. Sous 
le nom de Crystal, il a done propose une famille de methodes partageant 

1. H. Takeuchi and I. Nonaka, « The New New Product Development Game », Harvard Business 
Review, Jan-Feb 1986. 

2. K. Schwaber et M. Beedle, Agile Software Development with SCRUM, Prentice Hall, 2001. Voir 
aussi Scrum : Where Did Rapid Application Development Come From ? IEEE, 2003. 

3. A. Cockbum, Surviving Object-Oriented Projects, Addison- Wesley Professional, 1998. 
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certains principes, mais adaptees a la taille de l’equipe et aux enjeux du 
projet. Ceux-ci sont mesures par les consequences en cas d’erreurs dans le 
logiciel. Chacune porte un qualificatif colore (Clear, Yellow, Orange, 
Orange Web, Red, Maroon) 1 . 

Les methodes agiles, qui se sont d’abord qualifiees de methodes « legeres », 
partagent l’objectif de conduire le projet de fagon a livrer des applications de 
qualite dans des delais fortement reduits par rapport aux pratiques observees. 
Tous les auteurs de ce courant methodologique sont partis du constat que la 
dimension humaine est centrale dans les projets systeme d’ information, notam- 
ment ceux dont la partie developpement de logiciel est importante. Le manage- 
ment de ces projets devrait alors viser a stimuler la creativite des developpeurs, 
qui s’exprime en general dans des activites solitaires, tout en favorisant leur 
collaboration avec les autres acteurs concernes par le projet (clients, utilisateurs, 
manageurs...). L’exigence de delai court accroit la difficult^, car l’apprentissage 
du travail en commun doit etre rapide. 

Les methodes agiles ont donne lieu a des controverses methodologiques entre 
le camp des « agilistes » et celui des « structuralistes ». Certains proposent 
depuis quelques annees des rapprochements. 

Sans nous situer dans ces debats, nous avons adopte une position manage- 
ment de projet, c’est-a-dire que nous considerons d’abord qu’il y a des fondamen- 
taux dans la gestion de tout projet (par exemple, le schema propose au § 1.3.1), 
ensuite que l’unicite de chaque projet appelle des reponses adaptees et enfin que 
certaines techniques peuvent etre ponctuellement utilisees dans des projets tres 
divers. En effet, les recherches sur le management des projets informatiques 
depuis une vingtaine d’ annees montrent qu’il n’y a pas de reponse universelle 
pour tous les projets, mais que seule une approche dite « contingente », prenant 
notamment en compte les risques et l’incertitude, est pertinente 2 . De plus, une 
perspective historique fait apparaitre des emprunts ou des glissements d’une 
methode a l’autre. Certaines techniques de conduite de projet peuvent etre utili- 
sees de fagon ponctuelle ou accompagnees d’autres elements methodologiques. 
C’est ce qui a permis un rapprochement des cadres de management de projet 
dans des referentiels a large couverture. 

Cependant, une approche contingente et modulaire renvoie sur le responsa- 
ble du projet de nombreuses decisions : l’objectif de cet ouvrage est d’apporter 
des elements qui d’une part facilitent la comprehension de la situation du projet, 


1. A. Cockbum, Crystal Clear : A Human-powered. Methodology For Small Teams, Addison- Wesley 
Professional, 2004. 

2. Voir par exemple, C. Morley, « L’analyse a priori d’un projet systeme d’information », Colloque 
AIM, 1999. 
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d’autre part aide a elaborer les reponses pertinentes. Les principes et les techni- 
ques des methodes agiles rentrent dans cette panoplie d’outils methodologiques. 

C’est pourquoi, nous avons choisi de les presenter, non pas dans un chapitre 
a part, mais dans les chapitres traitant des differents aspects du management de 
projet. En particulier : 

• les modeles de cycle de vie propres a chacune des principales methodes 
agiles sont decrits au chapitre 2, ainsi que les principes de decoupage 
structurel ; 

• les approches d’estimation des charges de travail utilisees dans un environ- 
nement agile sont indiquees au chapitre 3 ; 

• les techniques de maitrise des delais specifiques aux methodes agiles figu- 
rent au chapitre 4 ; 

• les principes et modalites pour gerer l’equipe de developpeurs, pour faire 
participer les utilisateurs et pour favoriser une communication efficace au 
cours du projet sont decrits au chapitre 5 ; 

• les caracteristiques de gestion des risques des projets menes en mode agile, 
ainsi que les facteurs de choix d’une methode agile sont analyses au 
chapitre 6 ; 

• les questions de suivi et de mise sous controle d’un projet agile sont abor- 
dees au chapitre 7 ; 

• la recherche de qualite, objectif majeur des methodes agiles, donne lieu a 
des dispositions particulieres indiquees au chapitre 8. 

De plus, dans la troisieme partie de cet ouvrage, un chapitre recapitule les 
points de convergence et les eventuelles divergences entre le referentiel PMI et 
les methodes agiles. 

Apres cette rapide evocation des courants methodologiques recents sur la 
fagon de conduire un projet systeme d’information, nous allons maintenant 
etudier de fagon detaillee les differents aspects de son management. 



2 


Le decoupage d'un projet 
et les modeles 
de cycle de vie 


2.1 LES PRINCIPES DU DECOUPAGE 

Nous avons vu au chapitre precedent que le management de projet comporte 
trois aspects representes dans le triangle Projet : la production, les ressources et 
le temps. Une des premieres responsabilites du chef de projet est de decouper le 
projet pour pouvoir repartir dans le temps la production et les ressources. Le 
decoupage doit s’appuyer a la fois sur l’approche cartesienne de reduction de la 
difficulte 1 et sur l’approche systemique de prise en compte des liens entre les 
elements 2 . 

Decouper un projet consiste ainsi a identifier des sous-ensembles quasi auto- 
nomes, presentant les caracteristiques suivantes : 

• chaque sous-ensemble du projet donne lieu a un resultat bien identifie ; 

• la charge propre a chacun peut etre evaluee ; 


1. Le second principe presente par Descartes dans le Discours de la methode est de « diviser chacune 
des difficultes (...) en autant de parcelles qu’il se pourrait et qu’il serait requis pour mieux les 
resoudre ». 

2. Jacques Melese en presente les principes appliques a la gestion dans La gestion par les systemes, 
Edition Hommes et Techniques, 1977. 
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• les contraintes d’enchainement entre les sous-ensembles sont reperables : 
certains sous-ensembles peuvent etre realises parallelement, d’autres sont 
lies entre eux par des contraintes d’anteriorite ; 

• le decoupage est fait a des mailles differentes, un sous-ensemble etant souvent 
a son tour decompose. 

On utilise deux grands criteres pour decouper un projet : l’un est temporel, 
l’autre structurel. Ces deux criteres ne sont pas exclusifs. 

Le critere temporel est utilise dans la plupart des projets. II permet de repartir 
le travail dans le temps : la decomposition fait apparaitre une succession d’etapes 
et de phases. A chacune, on attache une date de debut prevue et une date de fin 
visee. La figure 2.1 en donne une representation avec le formalisme UML 
[Morley etal., 2006]. 

Un projet se compose de phases ; chaque phase comprend un certain nombre 
d’activites 1 ; une activite est definie par une ou plusieurs taches a effectuer. 
A chaque element de decomposition on attache un resultat a atteindre, appele 
livrable, qui peut faire l’objet d’un engagement contractuel. 



Figure 2.1 — Le decoupage temporel d’un projet. 


L’ ensemble ordonnance des phases d’un projet s’appelle le cycle de vie du 
projet. 

Le decoupage temporel poursuit deux objectifs : il balise et il guide. En effet, 
chaque date represente un jalon permettant de marquer les points de decision du 
parcours. De plus, la distribution dans le temps reflete un cheminement intellectuel. 


1. Parfois, la phase est decoupee en etapes, elles-memes composees d’activites ou de taches. 
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La plupart des methodes de conception de systeme d’information proposent un 
tel cheminement, souvent appele cycle de developpement ou modele de cycle 
de vie. Le decoupage temporel est souvent de type descendant (top 'down, du 
haut vers le bas), c’est-a-dire qu’il favorise : 

• une visibility croissante, car les resultats sont de plus en plus precis et la 
maille d’etude de plus en plus fine ; 

• une progression reelle des travaux, dans la mesure ou les resultats consolides 
en fin d’une etape ne sont pas remis en question dans les etapes suivantes. 

Dans tous les cas, le cheminement intellectuel permet de converger, c’est-a- 
dire d’eviter de partir continuellement sur de nouvelles pistes. II doit etre econo- 
mique, evitant de faire et defaire. Le client et le chef de projet ont tous deux 
interest a decouper le projet dans le temps, car ainsi : 

• Le client pent valider et orienter le projet. 

Le decoupage temporel permet au client de s’assurer progressivement que 
ce qui a ete congu traduit bien les objectifs generaux, de faire des choix, 
eventuellement de reorienter le travail. En general, la fin d’une phase se 
traduit par la livraison d’une foumiture contractuellement definie. La fin 
d’une activite donne lieu a la remise de produits intermediaires. 

• Le chef de projet pent baliser le deroulement du projet. 

S’il a decoupe son projet en tranches, le chef de projet peut effectuer une 
planification et en suivre pas a pas l’avancement. La fin de chaque tranche 
est comme un jalon ou il regarde plus particulierement s’il n’y a pas des 
signaux inquietants concemant l’etat de sante du projet. 

Le critere structurel permet d’organiser le travail en se basant sur la structure 
du produit final : la decomposition fait apparaitre les differents modules qu’il faut 
obtenir (figure 2.2). L’utilisation de ce critere requiert une visibility suffisante sur 
le resultat a produire. 


Projet 

est decoupe en 

Module 



1 1..* 




e decompose e\ 


Figure 2.2 — Le decoupage structurel d'un projet. 
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En plus du decoupage temporel et surtout si le projet est de taille importante, 
on recourt au decoupage structurel qui presente plusieurs avantages. 

• Maitriser le projet. 

Le decoupage conduit a des sous-ensembles coherents d’une taille plus 
reduite et plus facile a maitriser. 

• Repartir les responsabilites. 

L’autonomie des modules autorise leur repartition dans des sous-projets 
separes, dont la realisation est confiee a differents responsables ou even- 
tuellement sous-traitee. 

• Reduire les delais planifies. 

Certains modules independants sont developpes en parallele, ce qui 
permet d’avancer la date theorique d’achevement du projet. 

• Avoir un developpement incremental. 

Pour differentes raisons (taille, budget, delais), on choisit parfois de deve- 
lopper un systeme d’information par versions successives (en general trois 
ou quatre), chaque version comportant un nombre croissant de modules 
par rapport a la precedente. Le decoupage structurel est alors essentiel 
pour definir le contour de chacune d’elles. 


2.2 LES DECOUPAGES NORMALISES 

Les normes interna tionales proposent trois decoupages : PBS, WBS et OBS. 

Le decoupage PBS, Product Breakdown Structure (structure de decomposition 
du produit), correspond au decoupage structurel : ce sont les differents compo- 
sants du produit final. Soit par exemple un progiciel de gestion des valeurs mobi- 
lieres a developper (figure 2.3). Le PBS represente le decoupage du progiciel en 
modules, chacun assurant une fonction specifique. Trois principaux modules ont 
ete identifies : un referentiel des differents titres (la base Valeur), la tenue de la 
comptabilite Titres (comptabilite) et la gestion d’un carnet d’ordres passes sur les 
marches (ordres de Bourse). Ce dernier module contient a son tour deux parties : 
l’enregistrement des ordres (carnet d’ordres) et le traitement administratif des 
ordres effectivement passes (denouement). 

Le PBS est parfois appele « structure du produit » ou « arborescence produit », 
« representation des liens de composition entre les divers constituants d’un produit 
complexe » [AFITEP, 2000]. 

Le decoupage WBS, Work Breakdown Structure (structure de decomposition du 
travail), represente, sous forme d’une arborescence, les differents composants de 
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Figure 2.3 — Decoupage PBS simplifie. 



Figure 2.4 — Decoupage WBS simplifie. 


travail necessaries pour parvenir au resultat tel qu’il est decrit dans le PBS. II 
s’appuie, en general, a la fois sur le critere structurel et sur le critere temporel. 

L’AFITEP et l’AFNOR le definissent comme le « decoupage hierarchise et 
arborescent du processus de realisation en elements plus faciles a analyser et a 
maitriser, appeles lots de travaux ou taches ». II apporte une reponse aux deux 
questions : « Que doit-on faire ? Comment doit-on s’y prendre ? ». 

En reprenant l’exemple ci-dessus, le WBS pourrait se presenter comme illustre 
a la figure 2.4- 

L’on mene d’abord une conception generale sur l’ensemble sur domaine ; l’on 
poursuit le travail a travers trois sous-projets, dont on decidera, au moment de 
les planifier, de les mener ou non en parallele. Chacun comporte une phase 


0 


2. Le decoupase d'un projet et les modeles de cycle de vie 


de conception, puis un developpement et une phase de tests. Dans le cas du 
sous-projet Ordres de bourse, on a distingue deux phases de developpement, 
correspondant a chacun des sous-modules Carnet d’ordres et Denouement ; dans 
le cas du sous-projet Comptabilite, on s’appuie sur un progiciel existant qu’il 
s’agit de decouvrir et parametrer. Enfin, les trois logiciels issus des sous-projets 
font l’objet d’une integration. 

L’AFITEP traduit le terme anglais WBS par « Organigramme des taches » ou 
« OT ». L’lPMA considere cependant que l’OT est la representation graphique 
du WBS, sous forme d’un diagramme tel celui que nous presen tons au chapitre 4 
(reseau PERT ou diagramme des antecedents). Le logiciel MS Project, dans sa 
version 2003, utilise le terme OT dans cette meme acception. 

Le PMI propose pour WBS la traduction de SDP (Structure de decoupage du 
projet), comme nous l’indiquons au chapitre 17. Le niveau le plus has de l’arbo- 
rescence est appele « lot de travail ». Chaque lot de travail pourra ensuite etre 
decompose en activites pour une planification detaillee. 

L’OBS, Organisation Breakdown Structure (structure de decomposition de 
l’organisation), reprend le WBS et fait apparaitre les noms des personnes respon- 
sables de la production des differents elements. 

Dans notre exemple (figure 2.5), le chef du projet global a la responsabilite 
directe de la conception generale et de l’integration. Les trois sous-projets sont 
conduits par d’autres personnes, les differents travaux sont affectes aux ressources 
du projet. 



Figure 2.5 — Decoupage OBS simplifie. 
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L’OBS est parfois appele « organigramme fonctionnel » ou « OF ». II repre- 
sente « la structure des different^ niveaux de responsabilites de realisation de X ensem- 
ble des lots de travaux d’un meme organigramme des t aches » [AFITEP, 2000]. 


2.3 LE DECOUPAGE STRUCTUREL 

Le decoupage structurel repose sur la possibility de decouper le domaine en sous- 
ensembles quasi independants. II peut etre fait a plusieurs niveaux. 

Un premier niveau est celui du decoupage d’un systeme d’information en 
domaines. Un domaine peut etre defini comme un sous- ensemble du systeme 
d’information global, qui possede en propre des informations — e’est-a-dire 
qu’elles sont creees et mise a jour dans le domaine — et des processus. Cela 
implique que souvent un domaine est transversal a plusieurs entites de l’organi- 
sation (site, departement, service...). 

Un second niveau de decoupage est celui qui identifie des modules, comme 
dans l’exemple donne a la figure 2.3, illustrant le PBS. Chaque module peut 
etre a son tour decoupe en sous-modules. II y a en general deux fagons 
d’approcher ce decoupage en modules : par la vision statique ou par la vision 
dynamique. 

Le decoupage par la vision statique s’appuie sur une macromodelisation des 
entites, e’est-a-dire le reperage des principaux concepts d’information a l’aide d’un 
modele Entite-Relation ou un diagramme de classes UML. A chaque entite prin- 
cipale correspond un module. Dans l’exemple du domaine Gestion des valeurs 
mobilieres, le decoupage en trois premiers modules decoule de la vision statique 
(figure 2.6). En effet, une modelisation des entites ferait apparaitre trois principa- 
ls classes : Valeur mobiliere, Ordre de bourse et Ecriture comptable. 



Figure 2.6 — Decoupage structurel. 
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Le decoupage par la vision dynamique s’appuie sur une identification des 
principaux processus du domaine. A chaque processus correspond un module. 
Dans l’exemple du domaine Gestion des valeurs mobilieres, le decoupage du 
module Ordres de bourse en deux sous-modules decoule de la vision dynamique 
(figure 2.6). En effet, on a distingue deux processus : l’entree d’un ordre dans le 
carnet et sa transmission a une societe de bourse, en reponse a une demande d’un 
client ; le suivi du traitement de l’ordre, declenche par la reception de l’avis 
d’opere par la societe de bourse. 


2.4 LE CYCLE DE VIE STANDARD 

2.4.1 Le contenu du cycle de vie standard 

Le decoupage temporel des projets industriels relevant d’une production unitaire 
est la reference initiale : c’est celui que l’on trouve souvent dans les ouvrages 
traitant de gestion de projet. 

Ce cycle de vie standard se compose des phases suivantes : 

• etude de faisabilite ; 

• definition des solutions ; 

• conception detaillee ; 

• realisation. 


L ’etude de faisabilite comprend des travaux d’analyse, des travaux de recher- 
che, des etudes sur le terrain. II s’agit de verifier si le projet est techniquement 
realisable. Par exemple, si l’on veut construire un immeuble, il faut verifier que le 
terrain et le sous-sol le permettent, a un cout acceptable. 

La definition des solutions donne une representation precise de l’objectif a 
atteindre. Les solutions possibles sont etudiees de fagon detaillee. Pour cela, on 
utilise differents moyens, par exemple faire des essais, elaborer une maquette, 
construire un prototype. Au terme de cette phase, une solution est alors choisie 
et Ton dispose de specifications exactes. 

La conception detaillee sert a preparer les contrats de realisation. En effet, un 
grand projet industriel fait souvent intervenir des corps de metier differents. 
Ces contrats contiennent les cahiers des charges pour les sous-traitants. Les 
specifications techniques decrivent la mission et les moyens pour la realiser. 
Aucune ambigu'ite ne doit subsister. Meme si l’on ne recourt pas a des fournis- 
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seurs exterieurs, le principe du cahier des charges exhaustif est fondamental. 
Les fournitures livrees a l’etape suivante sont acceptees sur la base de son 
contenu. 

La realisation est l’execution des contrats par les sous-traitants, conformement 
aux cahiers des charges. Cette phase se termine en general par une procedure 
d’ acceptation officielle. 

Dans ce decoupage de reference, la realisation du projet passe par une defini- 
tion complete, precise et detaillee de l’objectif. Les trois premieres phases repre- 
sentent generalement 10 % des efforts et des depenses. Le management de 
projet (planification, organisation, suivi) porte essentiellement sur la phase 
de realisation. 


2.4.2 Les problemes poses par le decoupage standard 

Le decoupage temporel standard ne peut guere etre utilise tel quel dans un projet 
systeme d’information. 

D’abord la notion de cahier des charges y est declinee a plusieurs moments. 
En effet, la plupart des phases du cycle de developpement peuvent conduire a 
un cahier des charges qui oriente le travail de l’etape ulterieure. On parle alors 
d’un « cahier des charges d’analyse » ou d’un « cahier des charges de concep- 
tion » ou encore d’un « cahier des charges de realisation ». 

Ensuite, dans le decoupage temporel standard, on postule la possibility pour le 
client d’etablir une description complete de ce qu’il attend. Or, dans notre 
domaine, l’elaboration des specifications, c’est-a-dire la determination des besoins 
et des solutions adequates, est un probleme majeur. II y a souvent une construction 
progressive, qui s’appuie sur des allers-retours entre une solution de gestion et des 
possibility techniques. Les besoins ne preexistent pas, ils emergent. Pour le chef 
de projet, les etapes d’analyse et conception sont risquees. Une part non negligea- 
ble du budget y est consacree — jusqu’a 40 % — sans toujours atteindre la qualite 
esperee. Par consequent, la gestion de projet commence des le debut du projet. 

De plus, l’elaboration d’un cahier des charges de realisation est un travail 
couteux. En effet, l’ecriture de specifications souffre de l’absence de composants 
reutilisables. Par exemple, la definition d’un systeme de gestion des clients serait 
allegee si Ton pouvait reutiliser des fonctions standard (creation d’un prospect, 
mise a jour d’une personne...) sans les reconcevoir et les decrire integralement. 
Ce n’est malheureusement pas le cas. Dans le domaine industriel, le recours a la 
CAO (conception assistee par ordinateur), pour concevoir un nouveau produit, 
favorise (’utilisation de composants existants, elementaires ou agreges. On peut 
les modifier ou les assembler differemment, en obtenant automatiquement les 
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nouvelles cotes. Les ateliers de genie logiciel 1 , qui aident a concevoir un systeme 
d’information, offrent un metamodele et non des modeles concrets, que Ton 
pourrait Stocker dans une bibliotheque de composants conceptuels. 

Par ailleurs, on a peu de specifications implicates. Par exemple, avant de dessi- 
ner les plans d’un immeuble, on definit sa destination. II en decoule un certain 
nombre de specifications standard. Differents criteres (standing, segment de 
marche vise...) donnent des normes orientant la conception (materiaux, taille 
des pieces, garage...). Si Ton transposait a ce type de projet la demarche systeme 
d’information, l’immeuble serait congu avec la plupart des futurs occupants ! 

Pour elaborer des specifications, on est done conduit a chercher une approche 
permettant de produire un resultat de qualite, en maitrisant les couts et les delais. 

Dans les projets de systeme d’information, le probleme de faisabilite se pose 
aussi de fagon particuliere. Dans un sens, on peut toujours faire quelque chose, 
dans la mesure ou les contraintes ne sont en general pas d’ordre physique, mais 
techniques, financieres ou organisationnelles. Ce n’est pas tout ou rien, comme 
la fusee Ariane qui part ou ne part pas. Ainsi, il y a une vingtaine d’annees, une 
grande banque de Madagascar avait lance un projet de liaison avec ses agences. 
Compte tenu des infrastructures de telecommunication a l’epoque, le projet a 
mis en place un systeme reposant sur l’envoi de disquettes entre les sites. 

Cela rend le processus de developpement plus facile en phase finale, car on 
peut demarrer un systeme avec des fonctionnalites reduites ; mais plus perilleux en 
phase de conception parce qu’il peut s’ecouler beaucoup de temps avant d’ avoir 
une vision claire de ce qu’on va faire, et il arrive parfois que le projet s’enlise. 

Par exemple, dans la mise en oeuvre en 1991 du projet Relit (Reglement- 
livraison de titres), permettant de relier les acteurs bancaires de la place de Paris, 
les problemes de temps de reponse provenant de la capacite des machines et du 
reseau, ont conduit a fonctionner pendant une periode intermediaire avec un 
nombre limite de banques et societes de bourse. 

De fagon analogue, au demarrage du projet FNCV (Fichier national des cheques 
voles, tenu par la Banque de France) une partie de 1’ alimentation par les differents 
acteurs s’est faite par disquette, bande magnetique, voire declaration papier. 

En conclusion, on peut dire que dans le domaine qui nous interesse, le mana- 
gement de projet couvre l’ensemble du cycle et s’appuie sur des decoupages 
temporels pouvant s’eloigner du decoupage standard. 

1. AGL ou CASE : Computer Aided System Engineering (Ingenierie de systeme assiste par ordina- 

teur). On distingue parfois les AGL de conception (appeles upper-case en anglais) qui assistent 

lors de la partie amont du cycle et les AGL de realisation (appeles lower-case en anglais) qui 

allegent la partie aval. De plus en plus d’outils couvrent tout le cycle. 
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Nous allons d’abord decrire le decoupage classiquement utilise, que l’on 
retrouve dans beaucoup de methodes de conception. Puis nous presenterons un 
panorama des decoupages temporels generiques utilises dans notre domaine, 
souvent appeles modeles de developpement. Nous terminerons sur certains 
decoupages specifiques. 

2.5 LE DECOUPAGE CLASSIQUE 

Durant les deux dernieres decennies, les methodes de developpement de systeme 
d’information ont propose un decoupage temporel de reference, parfois appele 
« cycle de vie classique ». La figure 2.7 presente ce decoupage avec les corres- 
pondances entre le vocabulaire de la methode Merise [Nanci, 2001], celui de la 
methode SDMS, et celui issu de la methode MCP qui a servi de reference a 
la norme AFNOR Z67-101. 


NORME AFNOR 
Z67-101 

MERISE 

SDMS 


Schema directeur 


Etude prealable 

Etude prealable 


Exploration 

Observation 

DBS (Definition des besoins 
du systeme) 

Conception 

Conception/Organisation 

CAS (Conception de 

Appreciation 

Appreciation 

1’ architecture du systeme) 

Conception detaillee 

Etude detaillee 

SES (Specifications extemes 
du systeme) 

Realisation 

Etude technique 

SIS (Specifications internes 
du systeme) 


Realisation 

Programmation 



Test 

Mise en oeuvre 

Mise en oeuvre 

Conversion 



Installation 

Evaluation 

Qualification 

Bilan 


Figure 2.7 — Decoupage temporel classique 
des methodes de developpement S.l. 
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23.1 Le schema directeur 


SD EP ED ET REAL MEO QUALIF 


L’objectif d’un schema directeur est de definir le scenario devolution du patri- 
moine informa tique, sous l’un ou 1’ autre de ces trois angles : 

• evolution de l’architecture technique (materiels, reseaux) ; 

• evolution de l’architecture applicative (donnees communes, identifica- 
tion des domaines, evaluation des applications) ; 

• evolution de la fonction informatique (methodes, normes, outils). 

Le champ d’un schema directeur est l’entreprise tout entiere ou bien un grand 
secteur de l’entreprise ; on l’appelle alors schema directeur sectoriel. Ce type de 
projet est mene par une petite equipe (2 a 3 personnes), en un temps limite 
(quelques semaines). Le directeur informatique est directement implique, mais 
aussi les responsables des autres directions. 

Le resultat d’un schema directeur depend de l’objectif majeur. En general on a 
une photographie de la situation existante, un diagnostic et des orientations 
devolution choisies a partir de deux ou trois scenarios. 

Le travail sur l’architecture applicative debouche sur une cartographie des 
domaines et une modelisation des principaux concepts. Cela conduit a definir 
des objectifs et des priorites par domaine et par application. 


23.2 L’ etude preal able 
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C’est souvent a partir de ce point que Ton fait partir le cycle de vie d’un systeme 
d’information specifique a un domaine. On aborde une etude prealable soit a 
Tissue d’un schema directeur, soit hors de toute operation schema directeur, pour 
repenser une application vieillissante sur un domaine bien identifie ou pour repon- 
dre a un besoin nouveau. 

Par exemple, le domaine du credit a connu ces dernieres annees de profondes 
evolutions reglementaires et commerciales. L’ application gestion des prets est a 
la limite de ses possibility devolution et doit etre refaite. Dans le domaine 
commercial, on peut mener une etude prealable pour repenser le systeme d’infor- 
mation dans une optique de e-commerce. 
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L’objectif d’une etude prealable est double. D’une part, il s’agit de faire des 
choix structurants pour la future application : evaluer 1’ adequation de la solution 
aux objectifs, choisir eventuellement entre plusieurs solutions, evaluer l’investis- 
sement (budget, temps), ajuster la solution a l’enveloppe si cela est necessaire. 
D’ autre part, il s’agit de foumir une base de reference pour la suite du projet : le 
rapport d’etude prealable peut done etre considere comme un cahier des charges 
pour l’etude detaillee. 

Une etude prealable comporte trois etapes : observation, conception-organi- 
sation et appreciation. 

L’objectif de l’etape observation est de donner une representation pertinente 
du domaine etudie, suffisante pour porter un diagnostic et mettre en evidence 
des besoins. Le resultat comprend : 

• une structuration du domaine en processus, qui va ensuite guider un even- 
tuel decoupage structurel, pour etablir un WBS par exemple ; 

• le choix d’un sous-ensemble representatif (SER) : en effet, si le domaine 
est important, on va se limiter a une partie du domaine, en utilisant la 
notion de variante de procedure ; 

• une description du fonctionnement du SER ; 

• une description modelisee des donnees ; 

• un diagnostic. 

L’objectif de l’etape conception-organisation est de proposer une ou plusieurs 
solutions, aux niveaux conceptuel et organisationnel, sur tout ou partie du 
domaine. Le resultat comprend un modele de donnees consolide ou enrichi, ainsi 
qu’une description d’au moins une variante de chaque processus, avec les traite- 
ments et les regies de gestion. 

L’objectif de l’etape appreciation est d’une part de dresser un bilan des avanta- 
ges attendus et des couts previsibles (etude de rentabilite), d’autre part d’elabo- 
rer un plan pour la poursuite du projet. On peut ainsi identifier differents sous- 
projets qu’il faut ordonnancer. Le decoupage en sous-projets repose sur un 
decoupage structurel ; par exemple, on peut definir un sous-projet par processus. 
L’ordonnancement se fait selon : 

• une eventuelle priorite strategique de certains processus ; 

• la periodicite (traitements quotidiens, puis mensuels, puis annuels) ; 

• les contraintes logistiques (arrivee d’un materiel, mise en place d’un reseau). 


0 


2. Le decoupase d'un projet et les modeles de cycle de vie 


233 L' etude detaillee 


SD EP ED ET REAL MEO QUALIF 


L’objectif d’une etude detaillee est de concevoir et decrire de fagon exhaustive la 
solution sur tout le champ de l’etude. Elle sera ensuite completee par l’etude 
technique. Les specifications ainsi obtenues doivent faire l’objet d’un consensus 
entre futurs utilisateurs et informaticiens. Elies representent le cahier des char- 
ges pour la realisation. 

Le resultat comprend toute la vision externe du systeme : l’interface homme- 
machine (maquettes d’ecran, cinematique), la description des traitements a une 
maille suffisamment fine pour qu’il n’y ait plus d’ambiguite fonctionnelle, ainsi 
que les sorties (maquettes d’etat). On y ajoute souvent l’organisation a mettre en 
place et le planning detaille. 


23 A L’etude technique 

I SD I EP I ED I ET I REAL I MEO I QUALIF 


L’objectif de cette phase, qui ne conceme que les informaticiens, est d’optimiser 
les structures physiques de donnees et de construire les traitements (dossier 
programmes) en essayant de preparer la reutilisation du code. 

Le resultat comprend des normes techniques, des dossiers de programme et la 
structure physique des donnees. II complete le cahier des charges de realisation. 
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Cette phase est parfois appelee « developpement ». L’objectif est de produire un 
logiciel teste. Elle comprend done des taches d’elaboration de jeu d’essai, de 
programmation et de test. 

Elle se termine par une procedure d’acceptation officielle est appelee recette : 
le client foumit un jeu d’essai et verifie avec le foumisseur la conformite du logi- 
ciel a ce qu’il avait demande. Dans la pratique, la recette fait souvent une etape 
separee. On effectue parfois une recette provisoire apres la realisation et une 
recette definitive apres la mise en oeuvre. Dans une relation contractuelle donnant 
lieu a des flux financiers, la recette conditionne le paiement. 
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25.6 La mise en oeuvre 
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Uobjectif est de preparer le demarrage effectif de la nouvelle application. Cette 
phase comprend notamment le parametrage, la reprise ou 1’ alimentation des 
donnees, le developpement d’interfaces, la formation des utilisateurs, Installation 
d’environnement d’exploitation. La gestion du changement decrite au chapitre 5 
releve de la mise en oeuvre, qui souvent commence des la fin de l’etude detaillee. 

2*5.7 La qualification 

I SD I EP I ED I ET I REAL I MEO I QUALIF I 


Uobjectif est de realiser des tests dans l’environnement operationnel et de tirer 
un bilan du systeme d’information installe, selon different^ criteres qualite. Ces 
demiers sont presen tes au chapitre 8 qui regroupe tous les aspects de la qualite. 


2.6 LES MODELES DE DEVELOPPEMENT 


On considere aujourd’hui qu’on ne peut plus avoir une demarche unique, mais 
qu’il faut construire le decoupage temporel en fonction des caracteristiques de 
l’entreprise et du projet. On s’appuie pour cela sur des decoupages temporels 
generiques, appeles modeles de developpement (process models ) ou modeles de cycle 
de vie. 

Les principaux modeles sont : 

• le modele du code-and-fix ; 

• le modele de la transformation automatique ; 

• le modele de la cascade ; 

• le modele en V ; 

• le modele en W ; 

• le modele de developpement evolutif ; 

• le modele de la spirale. 
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2.6.1 Le model e du code-and-fix 

Ce modele repose sur la possibilite d’une determination facile des besoins 
(figure 2.8). Apres une etape breve de comprehension de l’objectif, l’application 
est developpee. Ensuite, plusieurs cycles de mise au point, parfois en collabora- 
tion avec l’utilisateur du futur systeme, permettent d’atteindre le resultat vise. 



Fin 

Figure 2.8 — Le modele du code-and-fix. 

2.6.2 Le modele de la transformation automatique 

Le modele de la transformation automatique ( transform model ) est base sur la 
possibilite de transformer automatiquement des specifications en programmes 
(figure 2.9). L’essentiel de l’effort va done porter sur une description exhaustive 
des specifications. Celles-ci devront etre completement validees. Une succes- 
sion de cycles de specification/validation s’acheve par la generation de code. 



Figure 2.9 — Le modele de la transformation automatique. 
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2.6.3 Le model e de la cascade 

Le modele de la cascade ( waterfall model ) est totalement oppose au modele du 
code-and'fix. II a comme objectif majeur de jalonner rigoureusement le processus 
de developpement et de definir de fagon precise les roles respectifs du foumisseur 
— qui produit un livrable — et du client — qui accepte ou refuse le resultat. 

Le decoupage temporel se presente done comme une succession de phases 
correspondant a une approche descendante (figure 2.10). Chacune donne lieu a 
une validation officielle : on ne passe a la suivante que si le resultat du controle 
est satisfaisant. Sinon, on modifie le livrable pour qu’il devienne acceptable. En 
revanche, il n’y a pas de retour possible sur les options validees a Tissue des 
phases anterieures. 
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Tests d’ integration^^ 

Implementation 
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Figure 2.10 — Le modele de la cascade. 


2.6.4 Le modele en V 

Ce modele (figure 2.1 1) est une amelioration du modele de la cascade. 

II vise, d’une certaine fagon, a reduire ce que Ton a appele l’« effet tunnel » : 
a partir d’un moment donne, les clients perdent la visibility sur le projet. Quand 
ce dernier ressort du tunnel, on decouvre des livrables qui ne sont pas toujours 
ceux que Ton attendait, non pas qu’ils ne soient pas conformes aux specifications, 
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Figure 2.1 1 — Le modele en V. 

mais parce les specifications sont parfois impuissantes a decrire les attentes. La 
seule validation de documents est done insuffisante. 

Dans le modele en V, on va done s’attacher dans chacune des phases de la 
premiere branche du Va expliciter les criteres depreciation et d’acceptation du 
systeme aux etapes correspondantes de la deuxieme branche du V. Par exemple, 
l’etude detaillee produira un jeu d’essai qui sera utilise pour effectuer la recette fonc- 
tionnelle. L’ installation sur un site pilote permettra de valider la definition 
fonctionnelle du besoin, d’apres les criteres exprimes dans cette etape. Le bilan 
global du projet verifiera que les objectifs initiaux formules dans l’etude d’oppor- 
tunite ont bien ete atteints. 

Pour les projets importants, il est recommande de decomposer le systeme en 
sous-ensembles (decoupage structurel) : l’etape de definition fonctionnelle du 
besoin conduit a un decoupage en composants, donnant lieu a etudes, realisations, 
tests et recettes separes, avant integration (figure 2.12). 

2.6.5 Le modele en W 

Ce modele enrichit le modele en V (figure 2.13 ) dans le meme esprit d’anticipation 
sur le livrable final. 

La premiere partie du W vise a degager avec les clients des orientations solides 
pour la conception ou bien a explorer les possibility d’une nouvelle technique. 
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Figure 2.12 — Le modele en V avec des composants. 



Figure 2.1 3 — Le modele en W. 


Le developpement de maquettes ou prototypes permet une validation plus concrete, 
voire une experimentation. 

2.6.6 Le modele de developpement iteratif 

L’objectif du modele du developpement iteratif, qui fut initialement appele 
evolutif (evolutionary design model), est de construire progressivement le systeme 
de fagon participative (figure 2 . 14 ). II repose sur l’idee que les besoins ne 


0 


2. Le decoupase d'un projet et les modeles de cycle de vie 


peuvent s’exprimer qu’apres une experimentation, meme sur un systeme rudi- 
mentaire ou incomplet. Chaque cycle aboutit a une nouvelle version du systeme : 
on s’arrete lorsque le client juge le systeme satisfaisant. 


Determination des besoms 
Programmation 

I 

Experimentation 

t 

version n 


Figure 2.14 — Le modele du developpement iteratif. 

Lorsque Ton veut indiquer que non seulement chaque iteration foumira au 
commanditaire un ensemble de fonctionnalites qui forment une version execu- 
table du systeme cible, mais que chaque version apportera de nouvelles fonction- 
nalites, on qualifie parfois le modele d’ incremental. 

Cependant, tout cycle iteratif n’est pas obligatoirement incremental : la 
premiere iteration peut livrer un systeme complet qui est ensuite affine et ajuste 
dans les iterations suivantes. 

2.6.7 Le modele de la spirale 

Le modele de la spirale ( spiral model ) repose sur le meme principe que le modele 
evolutif (figure 2.15), mais il s’inscrit dans une relation contractuelle entre le 
client et le foumisseur. De ce fait les engagements et validations presentent un 
caractere formalise. 

Chaque cycle donne lieu a une contractualisation prealable, s’appuyant sur 
les besoins exprimes lors du cycle precedent. Un cycle peut etre considere 
comme une phase, qui comporte les six etapes suivantes : 

• analyse du risque ; 

• developpement d’un prototype ; 

• simulation et essais du prototype ; 
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• determination des besoins (a des mailles differentes selon le cycle), a partir 
des resultats des essais ; 

• validation des besoins par un comite de pilotage ; 

• planification du cycle suivant. 

Le dernier cycle permet de developper la version finale et d’implementer le 
logiciel. 



2.7 LES MODELES DE CYCLE DE VIE SPECIFIQUES 

Certains decoupages temporels sont lies soit a une methode, soit a un type de 
projet bien particulier. Nous en proposons deux exemples : le decoupage preco- 
nise pour mettre en place un progiciel integre et le modele RUP propose par la 
societe Rational Software. 

Nous presentons dans le paragraphe suivant les modeles de cycle de vie que 
Ton trouve dans les methodes agiles, introduites brievement a la fin du chapitre 1 . 

2.7.1 Le cycle ERP 

La mise en place d’un progiciel de gestion integre, souvent appele du terme 
anglo-saxon ERP ( Enterprise Resource Planning) 1 s’appuie sur un decoupage 
specifique (figure 2.16). 
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Figure 2.1 6 — Le cycle ERP. 


En effet, il s’agit de construire, en tirant le meilleur parti du progiciel, un 
systeme ameliorant la performance de l’entreprise. Deux etapes doivent done 
etre menees en parallele : Description des processus et Formation au progiciel. 
Ensuite, il y a autant de cycles d’analyse — parametrage — prototypage qu’il y a 
de processus. La validation par le Comite de pilotage permet une simulation en 
grandeur reelle. Il faut alors prendre en compte ce qui est reste en dehors du 
champ couvert par le progiciel. 


2.7.2 Le modele RUP 

Le modele RUP ( Rational Unified Process ) est representatif d’une approche 
combinant plusieurs modeles. Sa structure fait l’objet d’un assez large accord, 
notamment parmi les praticiens (figure 2.17). Il peut etre lu de la fagon suivante : 


1 . Le cycle est constitue de quatre phases principales, que l’on retrouve globa- 
lement dans toutes les approches descendantes : etude prealable (opportu- 
nity), conception de la solution detaillee (elaboration), developpement de 
la solution (construction) et mise en oeuvre (transition) 


1. Pour une description detaillee des ERP, voir l’ouvrage de Jean-Louis Tomas, ERP et PG1 selec- 
tion, methodologie de deploiement et gestion du changement : Les cles du succes, les facteurs de risques, 
Dunod, 2007. 


Opportunity 
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Fisure 2.1 7 — Le cycle RUP. 
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2. II existe six types de taches qui, au lieu d’etre affectees exclusivement a 
une phase, se retrouvent a des degres divers dans chacune des phases. Par 
exemple, l’etude des besoins peut apparaitre jusqu’a la fin du projet, mais 
la plus grande partie est effectuee dans les deux premieres phases. L’imple- 
mentation (developpement) a principalement lieu dans la phase de 
construction, mais on peut realiser un prototype des la premiere phase. 
Certaines taches, comme la direction de projet, s’effectuent sur toute la 
duree du projet. 

3. Certaines phases peuvent etre menees de fagon cyclique. Ainsi, [’elabora- 
tion se fait en deux cycles, conduisant par exemple a la production de 
specifications externes (vision utilisateur) et specifications techniques 
(vision developpeur). La construction est iterative et incrementale. 

De plus, l’ensemble du modele represente un tour de spirale, dans le cas d’une 
approche globale en spirale. 


2.8 LES MODELES DE CYCLE DE VIE DES METHODES AGILES 

Toutes les methodes agiles prennent en compte dans leur modele de cycle de vie 
trois exigences : une forte participation entre developpeurs et utilisateurs, des 
livraisons frequentes de logiciel et une prise en compte de possibles changements 
dans les besoins des utilisateurs au cours du projet. C’est pourquoi toutes font 
appel, d’une fagon ou d’une autre, a un modele iteratif et incremental. 

De plus, elles preconisent en general des durees de cycle de vie des projets ne 
depassant pas un an. 

2.8.1 Le modele RAD 

Le cycle de vie RAD conjugue modele lineaire, structure en cinq phases, et 
modele iteratif pour la phase Construction du logiciel en plusieurs modules 
successivement livres 1 (figure 2.18). 

La participation des utilisateurs est placee au coeur du cycle. En effet, le 
deroulement d’une phase comprend une ou plusieurs sous-phases, et chaque 
sous-phase presente une structure a trois temps, dans laquelle la tenue d’une 
session participative joue un role central (figure 2.19). Des travaux preparatories 
rassemblent et construisent le materiau (modele ou prototype) qui sera ensuite 
discute par les different^ acteurs et ajuste. 

1. Pour une description detaillee, voir]. Hugues, B. Leblanc et C. Morley, RAD, une methode pour 
developpe r plus vite, InterEditions, 1997. 
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Figure 2.1 8 — Modele de cycle de vie RAD. 



Figure 2.19 — Structure ternaire des sous-phases RAD. 

Les techniques de controle des delais seront presentees au chapitre 4 et la 
forme des sessions, specifiques a RAD, au chapitre 5. 

2.8.2 Le modele DSDM 

La methode DSDM a evolue au cours des annees. L’actuelle version 1 distingue le 
cycle de vie du systeme et le cycle de vie du projet. Le premier comprend, outre 
les phases du projet lui-meme, une phase de pre-projet qui doit conduire au 
lancement du projet et une phase post-projet qui recouvre l’exploitation et la 
maintenance de l’application. 

Le cycle de vie du projet comprend cinq phases, dont deux sont cycliques 
(figure 2.20). Les fleches pleines indiquent un deroulement normal. Les fleches 
en pointille montrent des retours possibles a une phase anterieure, soit apres la 
phase Conception et construction, soit apres celle de Mise en oeuvre. 


1. La description de la version 4.2 est donnee sur le site du consortium DSDM : 
http://www.dsdm.Org/version4/2/public. 
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Figure 2.20 — Modele du cycle de vie du projet DSDM. 


Apres une Etude de faisabilite, la phase Etude du metier permet, a travers des 
ateliers ( workshops ) entre equipe de projet et manageurs, de definir le perimetre 
du projet, avec une liste d’exigences priori taires et une architecture fonction- 
nelle et technique du futur systeme. 

La phase Modelisation fonctionnelle est une suite de cycles. Chacun permet 
de definir precisement les fonctionnalites souhaitees et leur priorite. L’ accepta- 
tion par toutes les parties prenantes d’un prototype fonctionnel, sur tout ou 
partie du perimetre, permet de passer a la phase Conception et construction. 
L’objectif de cette phase est de developper un logiciel teste, par des cycles succes- 
sifs de developpement/acceptation par les utilisateurs. 

Les roles specifiques a DSDM et la dynamique d’animation sont presentes au 
chapitre 5. 

2.8.3 Le modele XP 

La methode XP, focalisee sur la partie programmation du projet, propose un 
modele iteratif avec une structure a deux niveaux : d’abord des iterations de 
livraison (release), puis des iterations de developpement (figure 2.21). Les 
premieres conduisent a livrer des fonctionnalites completes pour le client, les 
secondes portent sur des elements plus fins appeles scenarios qui contribuent a la 
definition d’une fonctionnalite. 
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Figure 2.21 — Cycle de vie XP. 


Apres une phase initiale d’Exploration des besoins, un plan de livraison est 
defini avec le client. Chaque livraison, d’une duree de quelques mois, se termine 
par la foumiture d’une version operationnelle du logiciel. Une iteration de 
livraison est decoupee en plusieurs iterations de developpement de courte duree 
(deux semaines a un mois), chacune donnant lieu a la livraison d’une ou 
plusieurs fonctionnalites pouvant etre testees, voire integrees dans une version 
en cours. 

De fagon plus detaillee, chaque iteration de developpement (figure 2.22) 
commence par Pecriture de cas d’utilisation ou scenarios ( user stories ), c’est-a- 
dire des fonctions simples, concretement decrites, avec les exigences associees, 
qui participent a la definition d’une fonctionnalite plus globale. Utilisateurs et 
developpeurs determinent ensemble ce qui doit etre developpe dans la 
prochaine iteration. Une fonctionnalite est ainsi decoupee en plusieurs taches. 
Les plans de test sont ecrits, les developpeurs sont repartis en binome (comme 
nous le developpons au chapitre 5), ils codent les taches qui leur sont affectees, 
puis effectuent avec les utilisateurs des tests d’ acceptation. En cas d’echec, on 
revoit les scenarios et on reprend la boucle. Sinon, on continue jusqu’a avoir 
developpe tous les scenarios retenus. Une version livrable est alors arretee et 
mise a disposition, ainsi que la documentation. 

Les approches d’estimation, les roles et le pilotage XP seront abordes respec- 
tivement aux chapitres 3,5 et 6. 
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Figure 2.22 — Modele XP d'une iteration de developpement. 


2.8.4 Le modele SCRUM 

SCRUM emprunte au vocabulaire du jeu le qualificatif des trois phases du cycle 
preconise (figure 2.23). 



Figure 2.23 — Modele SCRUM de cycle de vie du projet. 


La phase d’Avant-jeu ( pre-game ), Conception et architecture du systeme, se 
deroule de fagon structuree, en general lineaire, et permet de determiner le peri- 
metre, la base du contenu du produit a developper et une analyse de haut niveau. 

La phase de Jeu (game) est iterative et qualifiee d’empirique, dans la mesure 
ou le travail effectue ne fait pas l’objet d’une planification. Une iteration, dont la 
duree oscille entre une et quatre semaines, est appelee un Sprint, en reference a 
ces poussees rapides et fortes que les joueurs de rugby peuvent effectuer sur le 
terrain. Un Sprint est decoupe en trois sous-phases : 

• Developpement ( develop ) : il s’agit de determiner l’objectif vise au terme 
de l’iteration, de le repartir en « paquets » de fonctions elementaires, de 
developper et tester chaque paquet. 

• Emballage (wrap) : on referme les « paquets » et on les assemble pour faire 
une version executable. 
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• Revue ( review ) : une revue elargie permet de faire le point sur les proble- 
mes et l’avancement. 

• Ajustement ( adjust ) : ajuster le travail restant. 

La phase d’Apres-Jeu (postgame), Cloture, vise a livrer un produit complet et 
documente. Comme dans la premiere phase, on peut en planifier les taches et les 
derouler de fagon lineaire. 

Les roles, l’animation et le suivi d’equipe, y compris la notion de « melee » 
(scrum) sont decrites au chapitre 5. 

2.9 LE DECOUPAGE STRUCT UREL DANS LE CAS DES METHODES AGILES 

Lorsque Ton utilise un modele iteratif et incremental, notamment dans le cadre 
d’une methode agile, le decoupage en composants affectes a des iterations diffe- 
rentes est particulierement important. En effet, d’une part, chaque iteration doit 
pouvoir fournir un logiciel utilisable, d’autre part il est souhaitable que toute 
livraison produise sur le client un effet demonstrate. Ainsi, la premiere iteration 
doit convaincre de la pertinence de la conception, meme si le systeme est rudi- 
mentaire, et inciter a poursuivre. Les iterations suivantes doivent montrer une 
progression effective vers un produit stabilise. 

Par exemple, le cycle de vie d’un projet peut etre structure en trois livraisons : 
la premiere permet de livrer les fonctionnalites de base, la deuxieme l’ensemble 
des fonctionnalites souhaitees et la troisieme d’ameliorer les fonctionnalites. 

La determination de l’ordre de livraison des fonctionnalites est parfois une 
question delicate necessitant de mettre en balance differents arguments. 

Ainsi, le plus confortable pour les developpeurs est de commencer par les 
referentiels et de s’attaquer ensuite au developpement des processus utilisant ces 
structures de donnees. Cependant, ce choix peut s’averer peu mobilisateur pour 
les clients qui s’attendent a voir rapidement des fonctions qu’ils esperent creatrices 
de valeur ou pouvant repondre a un besoin urgent. De fagon analogue, il est 
preferable en dehors de toute contrainte, de selectionner d’abord les fonctionna- 
lites les plus simples pour aborder ensuite les plus complexes, ou les cas standard 
avant les cas particuliers. Mais ces choix, qui peuvent d’ailleurs etre incompatibles, 
risquent de ne pas emporter l’adhesion des utilisateurs, peu convaincus par l’apport 
annonce du nouveau systeme. De plus, si les utilisateurs ne partagent pas les memes 
objectifs, il est souvent conseille de commencer par ce qui est le plus consensuel 
pour batir des relations positives de travail en commun, avant de s’attaquer a des 
fonctions susceptibles de generer des positions conflictuelles. 
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On peut parfois utiliser la notion de « strate ». Par exemple 1 , dans un projet 
de developpement d’un nouveau telephone mobile chez Motorola, les strates 
correspondaient aux differents aspects du systeme (liaison radio, controle d’appel, 
liaison avec la base...) et chaque version du produit implementait a des degres 
divers des elements de chacune des strates, ce qui a permis d’avoir des retours des 
commanditaires beaucoup plus tot dans le deroulement du projet. 

La question du choix d’un modele de cycle de vie est traitee au chapitre 6, 
dans le cadre plus general du controle des risques. On peut cependant souligner 
un mouvement de rapprochement depuis quelques annees, visant a conjuguer un 
cycle classique global avec un cycle issu d’une methode agile pour une partie du 
projet 2 . Ainsi, DSDM expose des rapprochements avec XP, certains auteurs font 
de meme entre XP et RUP 3 . 

Pour conclure, il convient de poser la question : quel decoupage choisir pour 
un projet donne ? En fait, le choix d’un modele de developpement s’appuie sur 
l’analyse des caracteristiques du projet, et notamment l’analyse des risques. De 
plus, il ne suffit pas de selectionner un modele : il faut egalement l’instancier, 
c’est-a-dire en construire une version concrete adaptee au projet a mener, et le 
conjuguer avec le decoupage structurel et l’organisation du projet. Cela consti- 
tue ce que Ton appelle l’etablissement d’une strategic. Cet aspect est traite au 
chapitre 6, qui couvre revaluation des risques et la prise en compte du diagnostic 
risque dans un plan de management de projet. 


1. J. A Stark et R. Crocker, « Trends in Software Process : The PSP and Agile Methods », IEEE 
Software 20, 3, 89-91, 2003. 

2. Voir par exemple, les cas de ABB, Ericsson et Vodafone etudies par D. Karlstrom et P. Runeson, 
« Combining Agile Methods with Stage-Gate Project Management », IEEE Software 22, 3, 43- 
49, 2005. 

3. Voir par exemple P. Y. Cloux, RUP, XP, Architectures et outils, Dunod, 2003. 
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3.1 LA CHARGE ET LA DUREE 


Avant de presenter les methodes permettant d’estimer la charge d’un projet, 
nous allons preciser certaines notions, puis nous situerons les differents niveaux 
d’estimation, auxquels sont attaches des objectifs specifiques. 

II convient de bien distinguer charge et duree. 

La charge represente une quantite de travail necessaire, independamment du 
nombre de personnes qui vont realiser ce travail ; elle permet notamment 
d’obtenir un cout previsionnel. Elle s’exprime en jour-personne, mois-personne 
ou annee-personne. Un mois-personne represente l’equivalent du travail d’une 
personne pendant un mois, en general 20 jours. 

Ainsi, un projet de 60 mois-personne represente 1’ equivalent du travail d’une 
personne pendant 60 mois. Si on evalue le cout complet du mois-personne a 
50 K€ en moyenne, le projet sera estime a 3 M€. 

On mesure la taille des projets a leur charge. Les ordres de grandeur generale- 
ment retenus sont les suivants : 

• si la charge est inferieure a 6 mois-personne, c’est un tres petit projet ; 

• si la charge est comprise entre 6 et 12 mois-personne, c’est un petit projet ; 

• si la charge est comprise entre 1 2 et 30 mois-personne, c’est un projet moyen ; 

• si la charge est comprise entre 30 et 100 mois-personne, c’est un grand projet ; 

• si la charge est superieure a 100 mois-personne, c’est un tres grand projet, 
souvent mesure en annees-personne. 
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La duree depend du nombre de personnes. Soixante mois-personne, ce peut 
etre aussi bien une personne pendant cinq ans, cinq personnes pendant un an, 
dix personnes pendant six mois ou soixante personnes pendant un mois. Cepen- 
dant, intuitivement on sent bien que Ton ne peut pas faire n’importe quoi. 
Certaines methodes d’estimation proposent de respecter un rapport charge/duree. 
Nous le precisons plus loin. 


3.2 LES DIFFERENTS BESOINS D’ESTIMATION 

Les besoins d’estimation des charges se situent a differents niveaux. Prenons 
l’exemple du domaine Gestion de production par lots (figure 3.1). 


Niveau 

Exemple 

Projet 

Projet Gestion de production 

Phase 

Etude prealable du projet Gestion de production 
Etude detaillee du sous-projet Ordonnancement 

Etape/Activite 

Etape observation de l’etude prealable Gestion de production 

Tache 

Specification de la fonction Reservation en stock 
Ecriture du programme Plan de chargement des machines 


Figure 3.1 — Exemples de niveaux d’estimation. 


Un niveau correspond a un objectif. L’exigence de precision en est depen- 
dante. Souvent le but vise par une evaluation est lie au stade d’avancement du 
projet. Pour souci de simplification, nous presentons les besoins d’estimation tels 
qu’on les rencontre aux differents stades du cycle de vie classique detaille au 
chapitre precedent. 

Au niveau projet, on veut estimer la charge du projet complet. L’ordre de gran- 
deur est le mois-personne ou l’annee-personne. II y a plusieurs raisons pour faire 
une telle estimation : 

• determiner une enveloppe budgetaire ; 

• voir ce que « pese » le projet en termes d’effort ; 

• faire une estimation de la rentabilite de l’investissement ; 

• e valuer une duree vraisemblable du projet. 


3.2. Les differents besoins d'estimation 


a 


Au niveau phase, on cherche la charge d’une etape specifique. L’ordre de gran- 
deur est le mois ou la semaine-personne. Les objectifs d’estimation a ce stade 
sont les suivants : 

• Ajuster le decoupage. Si la charge est importante, on va chercher a la diviser 
en deux lots, geres comme deux sous-projets, qui pourront eventuellement 
etre livres a des dates differentes. 

• Sous-traiter. Foumisseur et client font chacun une estimation. Celle-ci est 
indispensable au premier pour ne pas s’engager a travailler a perte. Mais de 
son cote, le client peut recevoir en reponse a un appel d’offres des proposi- 
tions dont les prix varient de un a dix. Retenir le « moins disant » peut 
constituer un risque reel. II y a, a ce sujet, le cas celebre d’un projet de l’US 
Air Force. Bien que l’estimation initiale fut de 1 500 K$, une societe de 
services remporta le marche a 400 K$. Apres developpement d’un systeme 
incomplet, le fournisseur a negocie plusieurs avenants. Au final, le cout 
total fut de 3 700 K$, soit pres de dix fois le montant du marche initial et 
plus du double de l’estimation par le client. . . Ce surcout s’est accompagne 
de retards considerables sur le calendrier prevu. 

• Prevoir des delais pour planifier l’ordonnancement des etapes, ainsi que des 
operations complementaires comme la formation des utilisateurs. 

• Prevoir des ressources, pour planifier l’affectation d’intervenants (internes 
ou extemes) sur le projet. 

Au niveau etape {ou activite), l’estimation est necessaire pour : 

• faire une planification precise ; 

• annoncer un calendrier de remise des differents resultats intermediaries 
(entre les livrables de deux phases) ; 

• prevoir et effectuer un suivi du projet ou sous-projet, pour surveiller les 
ecarts ; 

• prevoir 1’ affectation des ressources, car il peut y avoir une montee en 
charge ou une diminution d’une etape a l’autre. 

Au niveau tache, il s’agit d’evaluer chacune des taches qui font generalement 
l’objet d’une affectation individuelle, par exemple la tache d’ elaboration du jeu 
d’essai Planification de production. L’ordre de grandeur est le jour-personne. 

L’estimation permet une planification au niveau le plus fin, qui est indispen- 
sable pour le suivi du travail de l’equipe. 
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Entre le niveau du projet et celui de la tache, la visibility est croissante, ce qui 
fournit des elements de plus en plus precis pour revaluation. C’est pourquoi on utili- 
sera des techniques differentes, selon le niveau ou se situe le besoin d’estimation. 


3.3 LES DIFFERENTES METHODES D’ESTIMATION 

33.1 Les non-methodes 

Citons tout d’abord des techniques parfois utilisees, que Ton peut cependant 
ranger dans la categorie des « non-methodes ». 

La methode dite de Parkinson n’a rien a voir avec la maladie du meme nom : 
elle fait reference a un auteur, historien et militaire, qui a traduit des observa- 
tions recurrentes d’un dysfonctionnement administratif sous forme d’une 
« loi »', stipulant que « le travail se dilate jusqu’a remplir le temps disponible ». 

Supposons que, pour realiser une tache, on dispose d’une personne pendant 
trois mois. En l’absence d’estimation, la vitesse d’avancement est, dans la plupart 
des cas, spontanement ajustee a la duree de disponibilite des individus. Plus la 
taille de l’equipe est importante, plus cette « loi » se trouve verifiee. L’estimation 
des charges est difficile, car elle ne resulte pas de la simple application d’une 
formule. Pour cette raison, certaines entreprises ne font guere d’estimation de 
leurs projets systeme d’information, considerant que « cela ne tombe jamais 
juste ». Cependant, la « loi » de Parkinson nous indique que, sans evaluation, on 
consomme en general beaucoup plus de temps, si Ton compare avec des projets 
analogues, et le travail s’acheve difficilement. 

La methode du marche consiste a considerer que la charge correspond au prix 
a proposer pour remporter l’appel d’offres. L’exemple du projet de l’US Air Force 
cite plus haut montre les limites de cette methode. II ne s’agit pas de nier les 
contraintes commerciales dans un marche concurrentiel. Une societe de services 
peut repondre a perte a un appel d’offres, dans l’espoir d’obtenir ulterieurement 
d’autres contrats dont la rentabilite compenserait la perte sur le premier. Cepen- 
dant, dans un tel cas, il est indispensable de faire parallelement une evaluation 
realiste, pour pouvoir planifier et organiser le projet sur des bases solides. 

33.2 Les methodes 

II existe cinq families de methodes d’estimation, qui ne sont pas forcement 
concurrentes, mais peuvent etre utilisees simultanement, ou a des moments diffe- 
rents du cycle de vie du projet : le jugement d’expert, l’estimation par analogie, 
l’estimation ascendante, l’estimation parametrique et l’estimation probabiliste. 

1. C. N. Parkinson en a publie la premiere version en 1955 dans le journal The Economist : 
http://alphal.montclair.edu/~lebelp/ParkinsonsLaw.pdf 
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3.3. Les differentes methodes d'estimation 


1. Le jugement d’expert 

Certaines estimations sont basees sur le jugement d’expert. Les experts sont, 
dans le cas des projets systeme d’information, des consultants ou d’autres chefs de 
projet experimentes, qui font appel a leurs connaissances explicites ou implicites, 
acquises au cours de leur vecu et leurs observations. La methode Delphi, que 
nous presentons au paragraphe 3.4, a formalise un processus de mise en commun 
d’expertise. 

£ L ’estimation par analogie 

Les estimations s’appuient sur les consommations de projets similaires pour 
lesquels on a conserve une memoire. Ces projets peuvent etre internes ou extemes 
a l’entreprise. Par exemple, on veut mettre en place une nouvelle Gestion des 
clients dans une banque A. On sait qu’un projet analogue mene par une banque B 
a coute 500 mois-personne et un projet analogue dans une compagnie d’ assurance 
a consomme 350 mois-personne. Ces deux estimations permettent d’avoir un 
ordre de grandeur. On va situer le projet a estimer par rapport aux deux projets 
connus, en determinant si les caracteristiques du projet le rapprochent davantage 
de la banque B ou de la compagnie C. 

On peut aussi se servir d’une reference interne, sur un autre domaine. On a deja 
fait un projet Gestion de carte bancaire, qui a coute 700 mois-personne, et un projet 
Gestion des credits qui a coute 1800 mois-personne. On estime que le domaine 
Depot-epargne est d’une complexity qui le situe entre les deux. On retiendra un 
chiffre d’environ 1200 mois-personne. 

L’estimation basee sur l’analogie doit prendre en compte les facteurs d’environ- 
nement. Ainsi, une Gestion des clients dans une petite banque d’affaires coutera 
en principe moins cher que dans une grande banque a reseau, notamment a 
cause des processus de decision et des procedures de qualification. 

Nous detaillons au paragraphe 3.5 deux methodes pouvant se rattacher a 
cette famille : la methode de repartition proportionnelle, basee sur l’hypothese que 
les differentes phases d’un cycle sont lies par une relation de proportionnalite ; la 
methode des ratios qui s’appuie sur l’observation de pourcentages stables entre 
differentes activites. 

3. L 'estimation ascendante 

Le principe de cette famille de methodes est d’ estimer la charge d’elements de 
travail (lot de travail, activite, tache...) et de totaliser ces estimations elemen- 
taires. Elle requiert done d’avoir realise une structure de decoupage du projet 
suffisamment fine. Nous decrivons au paragraphe 3.6 la methode devaluation 
analytique, qui est frequemment utilisee. 
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4. L’estimation parametrique 

Certaines methodes utilisent un modele mathematique, issu d’ analyses statis- 
tiques sur la relation entre un ou plusieurs parametres, qui sont des variables 
caracteristiques du projet, et la charge previsible. 

L’estimation parametrique est analogue a la technique des unites d’oeuvre 
utilisee en comptabilite analytique pour repartir des couts generaux de fagon 
simple, facile a calculer, uniforme (la meme regie s’applique a tous), et pas trop 
fausse dans le sens ou le resultat n’est pas trop eloigne de celui que Ton obtien- 
drait si Ton se livrait a un calcul direct et detaille. Par exemple, les couts d’entretien 
d’un immeuble sont repartis entre les differents Departements proportionnelle- 
ment a la surface occupee ; l’unite d’oeuvre est le metre carre, la valorisation se 
fait a partir d’un cout standard du metre carre. De meme les couts d’un Service 
approvisionnement qui travaille pour toute l’entreprise sont redistribues dans 
chaque service proportionnellement au nombre de commandes passees ; l’unite 
d’oeuvre est la commande, pour laquelle on determine un cout standard. 

Pour utiliser cette technique, il faut determiner une ou plusieurs unites d’oeuvre 
pertinentes, affecter un cout unitaire standard a chaque unite d’oeuvre (par exemple, 
en divisant un cout global precedemment mesure par le nombre total d’ unites 
d’oeuvre) et pouvoir denombrer les unites d’oeuvre. Les methodes basees sur un 
modele proposent done de reperer certains elements simples, a partir desquels on 
calculera l’effort necessaire. Nous allons presenter deux methodes, diversement 
utilisees : le modele Cocomo au paragraphe 3.7 et la methode des points de fonction 
au paragraphe 3.8. 

Les methodes d’ estimation parametriques s’inscrivent, totalement ou partiel- 
lement, dans un schema general (figure 3.2) comportant les etapes suivantes : 

• faire une estimation de la taille du projet a l’aide d’une unite de mesure ; 

• convertir la taille en charge ; 

• eventuellement ajuster la taille ou la charge brute en raison de certaines 
particularites du projet. 


Denombrement des unites d’oeuvre | 
| Taille 

Application des poids standard | 
^ Charge brute 
Application des facteurs correcteurs 


Charge ajustee 


Figure 3.2 — Schema general de l'estimation des charges a base de modeles. 


3.4. Le jugement d'expert .- la methode Delphi 
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5. /.’estimation probabiliste 

Nous avons regroupe dans cette famille des approches utilisees conjointe- 
ment avec d’autres methodes lorsque l’incertitude est elevee et que Ton cherche 
a reduire le risque d’une evaluation erronee. Nous presentons au paragraphe 3.9 
l’estimation a trois points et la methode de Monte-Carlo. 


3.4 LE JUGEMENT D'EXPERT : LA METHODE DELPHI 

Les methodes basees sur le jugement d’expert peuvent etre utilisees a differents 
moments et a differents niveaux (pour un projet entier ou pour une activite). On 
y recourt generalement lorsque l’on dispose de peu d’elements. Par exemple lors 
d’une etude de faisabilite ou d’opportunite, le jugement d’expert peut apporter 
une aide a la decision de poursuivre ou non le projet. 

La methode Delphi fut elaboree en 1948 par la Rand Corporation 1 , pour 
ameliorer les previsions economiques. C’est un domaine ou l’avenir est generale- 
ment incertain ; les avis des experts, bien que parfois divergents, apportent des 
eclairages precieux. Le nom Delphi fait reference a la pythie de Delphes, a qui 
Ton posait des questions et qui, en rendant son oracle, se faisait l’interprete de la 
reponse des dieux. Sa parole etait done comme celle des experts empreinte d’une 
grande autorite. 

Cette methode propose une demarche pour mettre en commun des juge- 
ments d’experts. Elle est utilisee dans differents domaines, dont l’estimation des 
charges d’un projet systeme d’ information. La demarche est la suivante : 

• Dans un premier temps, chaque expert propose une estimation en utilisant 
sa propre experience. 

• Dans un second temps, tous les jugements sont rendus publics, mais 
restent anonymes. Chaque expert peut alors modifier sa propre estimation 
ou la confirmer. Chacun doit bien sur considerer que tous les autres sont 
egalement des experts, ce qui le conduit a se poser des questions si ses 
propres estimations sont tres eloignees de celles des autres. 

• Dans un troisieme temps, les nouvelles estimations sont devoilees et chacun 
peut justifier son propre jugement. 

• Dans un dernier temps, chacun propose une revision de son estimation. 
Normalement, sans que Ton arrive toujours a un consensus, les resultats 


1. Une version est telechargeable sur le site de RAND : http://www.rand.org/pubs/research_ 
memoranda/RM5888/ 
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sont moins divergents qu’au premier tour. Dans tous les cas, cela permet de 
construire en commun une premiere analyse du projet. 

Cette methode, utilisee notamment dans les societes de services, peut compor- 
ter differentes variantes, selon le mode de communication entre experts (oral, 
ecrit, rapproche ou a distance...), le nombre de cycles de prevision et la 
conduite de la discussion (avec ou sans animateur exterieur...). Bien que forte- 
ment dependante de l’experience des experts, elle permet de depasser la dimen- 
sion strictement individuelle en organisant la confrontation collective des 
estimations. On considere, par ailleurs, qu’elle evite que certains exercent une 
trap grande influence sur les autres, ce qui biaiserait le resultat. 


3.5 L’ESTIMATION PAR ANALOGIE 

33.1 La methode de repartition proportionnelle 

La methode de repartition proportionnelle est utilisee au niveau du projet ou 
d’un ensemble de phases. Elle est basee sur des observations de projets anterieurs : 
la charge de chaque phase d’un projet devrait correspondre, avec un certain 
intervalle de tolerance, a un pourcentage de la charge globale. II existe plusieurs 
versions qui donnent des pourcentages indicatifs, chacune s’appuie sur un cycle 
de vie de reference. Cette methode est utilisee de trois fagons : 

• On a fait une estimation de la charge globale du projet, que Ton cherche a 
repartir dans le temps. 

• On a evalue l’une des phases, au moyen d’une autre methode, et Ton veut 
en deduire la charge des autres e tapes. 

• On est en cours de deroulement du projet, on a observe le temps deja 
consomme et on veut estimer celui des phases a venir. 

L’exemple de repartition donne a la figure 3.3 fait reference au cycle RUP 
(§ 2.7.3) et distingue la repartition en charge et la repartition en duree. Notons 
qu’il est toutefois rare d’evaluer la charge de la phase de mise en oeuvre au moyen 
d’un ratio. En effet, celle-ci comprend des activites diverses dont une partie est 
decrite au paragraphe traitant de la gestion du changement (5.4). II faut done 
comprendre ici la transition comme reduite a son aspect informatique de prepa- 
ration de l’exploitation. 

Une autre repartition classique est donnee a la figure 3.4. Ces ratios sont issus 
d’experiences positives et negatives de projet. Ils doivent etre consideres en partie 
comme des recommandations et en partie comme des regies. Ainsi, une etude 
prealable ne doit pas consommer plus de 10 % des ressources d’un projet ; ou bien 
on doit s’attendre a consommer deux fois plus en realisation qu’en etude detaillee. 


3.5. L’estimation paranalogie 
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Phase 

Charge 

Duree 

Opportunity 

5% 

10% 

Elaboration 

20% 

30% 

Construction 

65 % 

50% 

Transition 

10% 

10% 


Figure 3.3 — Repartition d'apres le cycle RUP. 

II s’agit done moins de les appliquer de fapon aveugle que de les prendre comme 
base, en comprenant les relations qui unissent les differentes phases. 


Phase 

Ratio 

Etude prealable 

10 % du total du projet (hors mise en oeuvre) 

Etude detaillee 

20 a 30 % du total du projet 

Etude technique 

5 a 15 % de la charge de realisation 

Realisation 

deux fois la charge d’etude detaillee 


Figure 3.4 — Repartition proportionnelle de la charge entre les phases 
du cycle classique. 


Pour ce qui est de la charge de l’etude prealable, on utilise egalement une 
repartition proportionnelle entre les etapes (figure 3.5). 


Etapes 

Pourcentage de la charge d’etude prealable 

Observation 

30 a 40% 

Conception/Organisation 

50 a 60 % 

Appreciation 

10% 


Figure 3.5 — Repartition proportionnelle entre les phases. 


Par certains cotes, 1 'etude detaillee est la phase la plus difficile a evaluer, car il 
n’y a pas de relation constante entre etude prealable et etude detaillee. Deux 
facteurs principaux sont sources de variation : la couverture et la maille. 

• La couverture est la partie du domaine deja etudiee par le sous-ensemble 
representatif. Parfois, le nombre de variantes de traitement restant a 
etudier est eleve. A l’inverse, dans le cas de petits projets sans variante de 
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procedure, etude prealable et etude detaillee sont confondues sans surcharge 
pour l’etude prealable. 

L’utilisation des principes de l’analyse de la valeur en conception conduit 
a limiter la variete des procedures elaborees et a favoriser la reutilisation 
d’elements de procedures deja congues ; ceci reduit la charge a la fois de 
1’etude detaillee et de la realisation. 

• La maille d’ etude mesure la precision de la description. Dans certains cas, le 
modele conceptuel representant les entites est presque complet, dans 
d’autres cas la structuration statique doit encore etre affinee. De meme les 
traitements peuvent-ils n’ avoir ete ecrits que dans les grandes lignes. 

La charge de V etude technique est liee a la charge de realisation, mais peut etre 
augmentee par exemple en cas de particularity ou de nouveaute technique. 

La charge de la phase de realisation est liee a celle de l’etude detaillee. Le ratio 
Charge d’etude detaillee/charge de realisation est base sur l’idee qu’il y a une 
relation entre l’effort pour produire un cahier des charges et celui pour le realiser. 
Le ratio est parfois utilise a l’envers. On fait une estimation de la charge de reali- 
sation en utilisant une autre methode et on divise par deux pour avoir la charge 
d’etude detaillee correspondante. 


3~5.2 La methode des ratios 

La methode des ratios est egalement une forme d’ estimation par analogie, 
c’est une variante de la repartition proportionnelle qui vise la relation entre 
deux activites. Elle est souvent utilisee pour estimer des charges complementaires au 
developpement de l’application (figure 3.6). II s’agit par exemple de l’encadre- 
ment du projet, de la recette et de l’elaboration de la documentation utilisateur. 


Activite 

Ratio 

Encadrement du projet : 

- a la phase de realisation, 

- aux autres phases. 

20 % de la charge de realisation 
10 % de la charge de la phase 

Recette 

20 % de la charge de realisation 

Documentation utilisateur 

5 % de la charge de realisation 


Figure 3.6 — Repartition proportionnelle des charges complementaires. 


Pour ce qui est de la charge d’encadrement, le ratio est plus eleve a la phase de 
realisation. En effet, classiquement, l’equipe de projet est la plus nombreuse a ce 
stade. La coordination assuree par le responsable augmente de fagon significative. 


3.5. L’estimation paranalogie 
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La charge de recette depend de la taille du logiciel. En effet, la recette est la 
procedure par laquelle le client maitre d’ouvrage et le foumisseur maitre d’oeuvre 
constatent ensemble que le produit (logiciel) livre correspond aux specifications. 

Les utilisateurs sont souvent impliques dans la procedure, ce qui prepare le 
demarrage du futur systeme. Les taches de recette comprennent : 

• l’elaboration des jeux d’essai de recette, qui doivent permettre de verifier que 
le systeme fonctionne et reagit correctement ; on batit de preference des cas 
simulant le traitement entier d’un evenement de gestion. Les jeux d’essai de 
recette sont destines a faire des tests de fonctionnalite et non de volume. 
Ces demiers ont pour objectif de verifier que l’application supporte bien un 
volume important de donnees et de transactions simultanees ; ils ne sont pas 
toujours necessaries ; 

• la preparation de Yenvironnement de recette : il faut extraire des parties de bases 
de donnees reelles pour tous les objets qui ne sont pas crees par l’application ; 

• I’execution de la recette : il faut executer successivement les traitements par 
lots et pointer les resultats ; les traitements transactionnels sont testes en 
presence des deux parties, client et foumisseur. Un proces-verbal est dresse. 

La charge d! elaboration de la documentation utilisateur est proportionnelle a la 
taille du logiciel. La plupart des logiciels developpes ont des aides utilisateurs 
integrees pour la partie transactionnelle. Il faut neanmoins generalement livrer 
un guide sur papier pour l’utilisateur de l’application. 

La charge de la phase de mise en oeuvre ne releve pas d’une estimation stan- 
dard. La mise en oeuvre est le passage de l’ancien systeme au nouveau. L’effort est 
souvent proportionnel au nombre et a la complexite des programmes ecrits, mais les 
evolutions organisationnelles (roles, responsabilites, apprentissages...) sont deter- 
minantes pour evaluer la charge. Si le futur systeme est implante sur plusieurs 
sites, il faut prevoir une charge additionnelle variant avec le nombre de sites. 

On applique parfois un ratio de 40 % sur la charge de realisation, ce qui indi- 
que une relation de proportionnalite avec la taille du logiciel. Mais cette estima- 
tion est en general affinee en fonction du nombre de sites et de leurs 
caracteristiques techniques, organisationnelles et humaines. 

De plus, elle doit etre completee par les problemes de basculement, c’est-a- 
dire de passage de l’ancien systeme au nouveau. La charge peut notamment 
varier en fonction de deux criteres : la complexite et le scenario. 

La complexite du passage situation avant/situation apres se mesure par le nombre 
d’anciens fichiers (entries logiques) touches et par le degre de restructuration des 
informations apportee par le nouveau systeme. Il faut en effet assurer ce qu’on 
appelle la « reprise » ou la « conversion », c’est-a-dire reprendre le contenu des 
anciens fichiers et les convertir selon les nouvelles structures de donnees. 
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Le scenario retenu peut etre ou non progressif. Si l’on bascule d’un coup, il y a 
moins d’interfaces pour gerer des situations intermediaires. Le risque est plus 
grand et la charge plus faible. 

Pour les grands systemes d’information, la mise en oeuvre est generalement 
un sous-projet a part entiere, dans la mesure ou l’on doit developper des 
programmes specifiques de reprise et de bascule. De plus, le scenario de mise en 
oeuvre peut concemer plusieurs projets. 

3*6 L’ESTIMATION ASCENDANTE : DEVALUATION ANALYTIQUE 

La methode devaluation analytique est souvent utilisee pour evaluer la charge 
de realisation, lorsque l’on a une visibility sur les composants a developper. Elle 
s’appuie sur une typologie des types de composants, classes par nature et souvent 
par degre de difficulty, specifiques de l’environnement : developpement classi- 
que, parametrage de progiciel, developpement d’un intranet... Les poids (en 
jours-personne) des types de composants peuvent varier en fonction de la 
productivity de l’equipe. 

Le tableau de la figure 3.7 donne l’exemple d’une typologie classique, sepa- 
rant programmes transactionnels et programmes par lots. Les poids indiques, en 
jours-personne, correspondent a des temps moyens. 


Type de transaction 

Facile 

Moyen 

Difficile 

Menu 

0,25 

0,5 

1 

Consultation 

1 

2,5 

4 

Mise a jour 

1,5 

3 

5 

Edition en temps reel 

1 

2 

4 

Type de programme par lots 

Facile 

Moyen 

Difficile 

Extraction 

0,5 

1 

1,5 

Mise a jour 

2 

3 

5 

Edition 

1,5 

2,5 

4 


Figure 3.7 — Exemple de typologie pour revaluation analytique 


Ce type de methode sert notamment, pour repondre a un appel d’offres, a evaluer 
le travail necessaire a partir d’un cahier des charges. On fait une estimation du 
nombre de composants a realiser en les ventilant par nature. 
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La charge obtenue, appelee charge de realisation, couvre la programmation, 
l’elaboration de jeux d’essai de test et la mise au point des programmes. Pour 
obtenir la charge complete, on rajoute en general : 

• pour les tests d’integration : 10 % de la charge de realisation. 

• pour l’encadrement : 20 % de la charge de realisation. 

Nous donnons a la figure 3.8 un exemple d’utilisation de la methode devaluation 
analytique, avec des composants d’une application intranet Notes/Domino. 


Complexite 

Facile 

Moyen 

Difficile 

Total 

Type composant 

N 

P 

C 

N 

P 

C 

N 

P 

C 


Vue 

8 

0,25 

2 

20 

0,5 

10 

12 

1 

12 

24 

Masque 

9 

0,5 

4,5 

6 

1 

6 

10 

2 

20 

30,5 

Navigateur web 




12 

0,5 

6 




6 

Agents 







20 

0,5 

10 

10 

Acces bases donnees 
extemes 




4 

0,25 

1 




1 

Programme lotusScript 

6 

0,5 

3 

3 

2,5 

7,5 

5 

3 

15 

25,5 

Reprise donnees 







1 

9 

9 

9 

Total Realisation 










106 

Integration 








10% 


10,6 

Encadrement 








20% 


21,2 

TOTAL PROJET 










138 


Figure 3.8 — Exemple devaluation analytique 
N = nombre, P = poids C = charge 


3 .7 L’ESTIMATION PARAMETRIQUE i LE MODELE COCOMO 

Le modele Cocomo ( Constructive Cost Model, modele de construction des couts) 
a ete propose en 1981 par B.W. Boehm [Boehm, 1984]. Ce modele repose sur 
deux hypotheses : 

• d’une part, un informaticien chevronne sait plus facilement donner une 
evaluation de la taille du logiciel a developper que faire une estimation du 
travail necessaire ; 
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• d’ autre part, il faut toujours le meme effort pour ecrire un nombre donne de 
lignes de programme, quel que soit le langage de troisieme generation employe. 

Ces deux hypotheses ont conduit B.W. Boehm a calculer des coefficients de 
correlation entre la taille du logiciel et la charge consommee a partir d’observa- 
tions sur une centaine de projets deja realises. 

Le parametre utilise par ce modele est V instruction source. II faut done disposer 
du nombre presume de lignes de programme en langage source, en dehors 
d’eventuels commentaires. 

Le modele permet d’obtenir la charge de la realisation en mois-personne, ainsi que 
le delai « normal », recommande si on ne veut pas prendre de risques supplemental' 
res. Cela nous indique la taille moyenne de l’equipe qui est egale a charge/delai. 

Les formules de calcul de la charge et du delai sont les suivantes : 

Charge en mois-personne = a (kisl) b 
Delai normal en mois = c (charge en mois-personne) d 

avec kisl = nombre de milliers destructions sources livrees, e’est-a-dire le 
nombre de milliers de lignes de programme source testees. 

Les parametres a, b, c et d prennent des valeurs differentes selon la categorie 
de projet. En effet, l’analyse statistique a conduit a distinguer trois types de 
projet : simple, moyen et complexe. 

• Un projet est simple si le logiciel comporte moins de 50 000 instructions, si 
les specifications sont stables et le developpement effectue par une petite 
equipe. 

• Un projet est moyen si le logiciel comporte entre 50 000 et 300 000 
instructions. 

• Un projet est complexe si le logiciel comporte plus de 300 000 instructions et 
si l’on prevoit une equipe nombreuse ; il s’ applique souvent a un domaine 
nouveau. 

Les valeurs des parametres sont les suivantes (figure 3.9) : 


Type projet 

Charge en mois-personne 

Delai en mois 

Simple 

Charge = 2,4 (kisl) 1 ’° 5 

D = 2,5 (Charge) °’ 38 

Moyen 

Charge = 3 (kisl) x - 12 

D = 2,5 (Charge) °- 35 

Complexe 

Charge = 3,6 (kisl ) 12 

D = 2,5 (Charge) °’ 32 


Figure 3.9 — Formules du modele Cocomo. 
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Soit par exemple un projet simple visant a developper un logiciel estime a 
40 000 instructions sources : 

Charge = 2,4 x (40) 1,05 = 116 mois-personne (arrondi) 

Delai normal = 2,5 x (116) 0,38 = 12 mois (arrondi) 

Taille moyenne de l’equipe =116/12 =9 personnes. 

La methode Cocomo prend en compte des caracteristiques propres au projet 
pouvant modifier l’estimation de la charge. Ces caracteristiques 1 se traduisent 
par un coefficient de ponderation appele « facteur correcteur ». Les valeurs des 
coefficients donnees par B.W. Boehm et obtenues de fagon statistique sur un 
echantillon limite et biaise (les projets de sa propre societe TRW) sont de moin- 
dre interet que la demarche de correction. Celle-ci repartit les facteurs selon 
quatre sources de risques (figure 3.10) : les exigences attendues du logiciel, les 
caracteristiques de l’environnement technique (materiel), les caracteristiques de 
l’equipe projet et l’environnement du projet lui-meme. 


Logiciel 

Personnel 

Fiabilite 

Competence des concepteurs 

Base de donnees 

Experience des concepteurs 

Complexite 

Competence des developpeurs 

Temps d’execution 

Connaissance de l’environnement technique 


Experience du langage 

Materiel 

Projet 

Taille memoire 

Utilisation d’une methode 

Stabilite de l’environnement 

Utilisation d’un atelier de genie logiciel 

Disponibilite de la machine de test 

Contrainte de delai 


Figure 3.10 — Facteurs correcteurs du modele Cocomo. 


La fiabilite est le degre de regularity exige ; dans le cas de systemes mettant en 
jeu la vie humaine (controle du trafic aerien) ou pouvant causer des pertes finan- 
cieres importantes (systeme temps reel de reservation), ce facteur aura une 
influence forte. 

Le facteur base de donnees est mesure par le ratio : 

(volume de donnees gerees en octets) sur (taille du logiciel en lignes). 

1. En anglais, on les appelle des cost'drivers, des generateurs de cout. 
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Ainsi, si on gere 100 kilo-octets pour 1 000 lignes de programme, le ratio sera 
100. La methode considere que l’influence du facteur est faible si le ratio est infe- 
rieur a 10, moyenne entre 10 et 100, forte entre 100 et 1 000 et tres forte si le 
ratio est superieur a 1 000. 

La complexity est celle des algorithmes a developper. 

Le temps d! execution peut etre crucial pour certains systemes temps reel, comme 
le controle du trafic aerien ou le systeme de cotation des valeurs mobilieres. 

Le facteur taille memoire signifie qu’il y aura besoin d’optimiser l’utilisation de 
la memoire. 

La stabilite de V environnement est celle du logiciel de base. 

La contrainte de delai se mesure par rapport au delai « normal ». 

Chaque facteur peut prendre ses valeurs dans un intervalle specifique, dont 
les valeurs resultent de l’analyse statistique des projets de reference. Ils modifient 
la charge brute de fagon multiplicative : 

Charge nette = Produit( valeurs des facteurs correcteurs) * Charge brute 

La methode Cocomo propose done une demarche en cinq temps : 

• estimation du nombre d’instructions sources e’est-a-dire en langage de 
programmation ; 

• calcul de la charge dite « brute » ; 

• selection des facteurs correcteurs ; 

• application des facteurs correcteurs a la charge brute pour obtenir la 
charge dite « nette » ; 

• evaluation du delai normal. 

Les facteurs correcteurs sont a utiliser avec precaution pour deux raisons : 
d’une part, avec les valeurs proposees par B.W. Boehm, l’estimation peut varier 
de 1 a 17, a cause de l’effet multiplicatif ; d’ autre part, les valeurs proposees resul- 
tent d’un echantillon de projets specifiques. B.W. Boehm propose que chaque 
entreprise constitue sa propre base d’experiences. 

La methode Cocomo a fait l’objet devolutions sous le nom de COCOMO II 1 , 
rendues publiques a partir de 1997. Elle propose un affinement des parametres de 
contexte et inclut des projets au stade de l’analyse, en s’appuyant notamment sur 
la methode des points de fonction. Ce point est developpe plus loin au paragra- 
phe 3.8. 


1. Ces evolutions se font principalement a l’universite de Southern California, sous la direction 
de B.W. Boehm, qui y dirige un centre d’ingenierie logicielle. Beaucoup d’informations sont 
accessibles via internet, notamment a l’adresse : http://sunset.usc.edu/COCOMOII. 
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3.8 L’ESTIMATION PARAMETRIQUE : LA METHODE DES POINTS DE FONCTION 

Presentee pour la premiere fois par Alan Albrecht d’lBM en 1979, cette methode 
a ete experimentee par beaucoup de grandes entreprises clientes d’lBM, avec 
quelques difficultts d’interpretation et de denombrement des unites d’oeuvre. 
Un guide de comptage, publie en 1984, a favorise sa diffusion. Des associations 
d’utilisateurs se sont constitutes : 1’IFPUG (International Function Point Users 
Group) ftdere des associations nationales, et diffuse des versions mises a jour du 
guide de comptage. En France la FFPUG (French Function Point Users Group) 
s’est constitute en 1992, regroupant principalement des grandes entreprises, des 
construe teurs de mattriel informatique et des socittts de services. Elle a organist 
pendant plusieurs anntes des partages d’exptrience et traduit les guides de 1’IFPUG. 
En 1995, l’AFNOR a tdiett une norme sur la mise en oeuvre de la mtthode 1 . 

Le principe de la mtthode des points fonctionnels est de faire une estimation a 
partir dune description exteme du futur systeme, de ses « fonctions » ou compo- 
sants « fonctionnels ». On identifie cinq types avec trois degrts de complexitt. A 
chaque type et chaque degrt est affeett un nombre de « points », ce qui permet de 
calculer, pour un projet donnt, son poids en points de fonction. Difftrentes regies 
permettront de passer des points de fonction a une charge. 

La mtthode propose de faire un comptage des points au dtbut du projet en 
faisant des hypotheses sur les fonctions du futur systeme et de refaire un comp- 
tage en fin de projet bast sur les fonctionnalitts livrtes. L’tcart tventuel est 
appelt « changement d’envergure » du champ d’ttude. 


3.8.1 Les composants fonctionnels 

Cinq types de composants fonctionnels servent d’unitts d’oeuvre. Deux sont 
relatifs a l’aspect statique d’un systeme d’information (GDI et GDE) et trois a 
l’aspect dynamique (ENT, SOR et INT). 

Un GDI (Groupe de Donntes Interne) est un groupe de donntes que l’utili- 
sateur perqoit comme logiquement lites. II est ertt et mis a jour a l’inttrieur du 
domaine d’ttude. Si Ton se rtfere au formalisme entitt/association d’une modt- 
lisation conceptuelle, on peut assimiler le GDI a une entitt du modele conceptuel 
ou a une association porteuse de proprittts, qui correspond a un objet de gestion. 

Ainsi, une entitt Date n’est pas un GDI. Un lien de composition entre deux 
entitts conduit a retenir un seul GDI pour les deux entitts. Si par exemple, dans 
le domaine Credit, une entitt echeance a recouvrer se dtcompose en plusieurs 
entitts composante d’ echeance (capital, inttrets, assurance.), on considere l’ensemble 
comme un seul GDI. De fagon plus large, les entitts relites a d’autres par une 


1. AFNOR XP Z67-160 : « Technologies de l’information - Mesure de la taille de logiciel - Guide 
operatoire de comptage des points de fonction ». 
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relation de cardinality (1,1) sont susceptibles d’etre regroupees en un seul GDI si 
elles traduisent un meme concept de gestion. 

Un GDE (Groupe de Donnees Externe) est un groupe de donnees que l’utili- 
sateur pergoit comme logiquement liees. Le domaine d’etude ne fait que l’interroger. 
II est cree et mis a jour par un autre domaine. Un GDE est done obligatoirement 
un GDI dans un autre domaine. 

Une ENT (Entree) est une fonction elementaire, significative pour l’utilisateur, 
qui permet d’introduire des donnees a l’interieur du domaine. Ces donnees peuvent 
etre des donnees specifiques du domaine ou des parametres de traitement. L’entree 
des donnees declenchera un traitement comprenant des mises a jour. C’est une 
fonction autonome qui laisse l’application dans un etat de coherence fonctionnelle. 
Par simplification, une entree correspond a un ecran de saisie ou a une reception de 
donnees provenant d’une autre application et provoquant une mise a jour. A 
chaque GDI doit correspondre au moins une entree permettant sa mise a jour. 
Chaque entree (ENT) permet de saisir un certain nombre de champs, qui sont des 
donnees elementaires (DE). On compte une seule DE pour un champ repetitif. 

Une SOR (Sortie) est une fonction elementaire, significative pour l’utilisa- 
teur, qui envoie des donnees vers l’exterieur du domaine et qui n’effectue aucune 
mise a jour a l’interieur du domaine. C’est une fonction autonome qui laisse 
l’application dans un etat de coherence fonctionnelle. Par simplification, une 
sortie correspond a la generation d’un etat elementaire, d’un ecran de visualisa- 
tion ou d’un message a destination d’une autre application, avec des donnees 
calculees ou derivees, e’est-a-dire obtenues a partir d’autres donnees. Sur chaque 
sortie figurent un certain nombre de champs, qui sont des donnees elementaires 
(DE). On compte une seule DE pour un champ repetitif. Si deux sorties ont la 
meme logique de traitement et les memes DE (par exemple, sortie papier et 
sortie ecran), on ne comptera qu’une seule SOR. 

Une INT (Interrogation) est une fonction elementaire, qui a pour resultat 
l’extraction de donnees. La demande d’interrogation peut etre saisie ou provenir 
d’une autre application. Le resultat de Pinterrogation ne contient aucune donnee calcu- 
lee ou derivee, e’est-a-dire obtenue a partir d’autres donnees. L’INT ne met a jour 
aucun GDI. Sur le resultat de [’interrogation figurent un certain nombre de 
champs, qui sont des donnees elementaires (DE). On compte une seule DE pour 
un champ repetitif. Si deux interrogations ont la meme logique de traitement et 
les memes DE (par exemple, resultat papier et resultat ecran), on ne comptera 
qu’une seule INT. 

3.8.2 La complexity et le nombre de points de fonction 

Un GDI ou un GDE est compose de donnees elementaires (DE), qui correspon- 
dent aux proprietes d’une entite conceptuelle ou logique. On compte une DE 
par champ, y compris pour les cles etrangeres. 
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On peut parfois identifier plusieurs sous'ensembles bgiques de donnees (SLD) a 
l’interieur d’un GDI/GDE. Un SLD est un sous-groupe de donnees elementaires 
reconnaissable par l’utilisateur. Dans un modele de classes UML, un SLD peut 
etre assimile a une entite specialisee : on compte un SLD pour l’entite generale 
et un SLD par entite specialisee. 

La complexite d’un GDI ou d’un GDE est fonction du nombre de DE et du 
nombre de SLD, selon la figure 3.11. 

Une ENT utilise, en lecture ou mise a jour, differents groupes logiques de 
donnees, internes ou externes (GDI ou GDE), que Ton appelle de fagon generale 
des GDR, groupes de donnees references. Une SOR ou une INT utilise, en lecture 
uniquement, differents GDR. 

La complexite d’une ENT, d’une SOR ou d’une INT est fonction du nombre 
de DE et du nombre de GDR impliques, selon le tableau de la figure 3.11. 


GDI 


1 a 19 DE 

20 a 50 DE 

51 DE ou plus 


1 SLD 

Faifile 

Faible 

Moyenne 


2 a 5 SLD 

Faible 

Moyenne 

Elevee 

GDE 

6 SLD ou plus 

Moyenne 

Elevee 

Elevee 



1 a 4 DE 

5 a 15 DE 

16 DE ou plus 

ENT 

0 ou 1 GDR 

Faible 

Faible 

Moyenne 

2 GDR 

Faible 

Moyenne 

Elevee 


3 GDR ou plus 

Moyenne 

Elevee 

Elevee 

SOR 


1 a 5 DE 

6 a 19 DE 

20 DE ou plus 


0 ou 1 GDR 

Faible 

Faible 

Moyenne 


2 a 3 GDR 

Faible 

Moyenne 

Elevee 

INT 

4 GDR ou plus 

Moyenne 

Elevee 

Elevee 


Figure 3.1 1 — Evaluation de la complexite des composants. 


Le tableau de la figure 3.12 donne, selon son degre de complexite, le nombre 
de points de fonction correspondant a chaque composant fonctionnel. 


Degre de complexite du composant 

Faible 

Moyenne 

Elevee 

Nombre de points de fonction du GDI 

7 

10 

15 

Nombre de points de fonction du GDE 

5 

7 

10 

Nombre de points de fonction de l’ENT 

3 

4 

6 

Nombre de points de fonction de la SOR 

4 

5 

7 

Nombre de points de fonction de 1’INT 

3 

4 

6 


Figure 3.12 — Nombre de points de fonction des composants. 
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3.8.3 L’ajustement de la taille 

La premiere etape de la methode des points fonctionnels est un denombrement 
des differents composants fonctionnels et de leur degre de complexite : la somme des 
points de fonction de chaque composant est appelee nombre de points de fonction 
brut (PFB). 

La seconde etape, qui est facultative, consiste a ajuster revaluation obtenue. 
On corrige le nombre de points de fonction brut, en appreciant les specificites du 
projet pouvant influer sur l’effort. Ce sont des fonctionnalites techniques et 
ergonomiques foumies a l’utilisateur de l’application. La methode en identifie 
quatorze, appelees CGS, caracteristiques generales du systeme. Chacune se voit 
attribuer une note, comprise entre 0 et 5, en fonction de 1’ influence qu’elle 
exerce : on l’appelle le DI, degre d’ influence. Les CGS et les valeurs associees sont 
donnees en annexe B. 

L’ analyse des caracteristiques permet de calculer un degre d’ influence total, le 
DIT, compris entre 0 et 70 : 

DIT = Somme (DI,) avec i = 1 a 14. 

Le facteur d’ajustement FA permet d’ajuster le nombre de points de fonction 
brut (PFB) de + ou - 35% : 


FA = 0,65 


DIT 

100 


pour obtenir le nombre de points de fonction ajuste (PFA) : 


PFA = FA * PFB 


Chaque caracteristique isolement ne peut faire varier le nombre de PFB que 
de 35/14 = 2,5 %. Ce point a fait l’objet de discussions, car certaines caracteris- 
tiques peuvent peser beaucoup plus lourd. 

En pratique, l’application du facteur d’ajustement n’est pas systematiquement 
realisee, surtout quand on fait l’estimation au stade de l’etude prealable. Certains 
choisissent d’evaluer la complexite globale du projet sans passer par revaluation 
analytique des CGS. D’autres preferent s’en tenir au nombre brut. 


3.8.4 La transformation du nombre de points de fonction en charge 

Le coefficient de transformation est variable selon l’environnement materiel et 
humain. 11 est recommande que chaque entreprise etablisse sa base de projets 
pour determiner ses propres coefficients. 

Certains auteurs ont considere qu’on pouvait etablir une correspondance 
entre la taille « fonctionnelle » de l’application et la taille du logiciel corres- 
pondant. Ils proposent une formule de transformation du nombre de points de 
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fonction en nombre d’instructions sources livrees 1 qui prend en compte le 
langage de programmation que Ton envisage d’utiliser. Cette transformation 
permet alors d’appliquer le modele Cocomo II. 

En general, on calcule la charge en convertissant directement le nombre de 
points de fonction. Les estimations generalement retenues sont les suivantes : 

• En fin d’etude prealable : 3 jours par point de fonction, 2 jours s’il s’agit 
d’un petit projet, 4 jours s’il s’agit d’un grand projet. 

• En fin d’etude detaillee : 1 a 2 jours par point de fonction selon l’environ- 
nement. 

Ainsi, en fin d’etude detaillee, un projet de 80 points de fonction « pese » en 
general 160 jours-personne en environnement grand systeme et 80 en environ- 
nement client-serveur. 

La reference aux points de fonction dans les methodes agiles est developpee 
au § 3.11. 


3.9 L’ESTIMATION PROBABILISTE 

Lorsque l’incertitude est elevee il est parfois preferable de prendre en compte 
plusieurs valeurs d’estimation. On va presenter deux approches : l’estimation a 
trois points et la methode de Monte-Carlo. 

L ’estimation a trois points peut etre utilisee a tous les niveaux, projet, phase, 
activite ou tache. Elle consiste a rechercher non pas avec une, mais trois valeurs 
d’estimation : 

• une valeur optimiste (f), c’est-a-dire faible car on fait l’hypothese qu’on ne 
rencontrera aucun probleme (disponibilite des ressources, productivity, 
relations avec le client ou les utilisateurs...) ; 

• une valeur pessimiste (F), qui est elevee car on suppose que Ton va se 
heurter a de nombreuses difficultes ou imprevus ; 

• une valeur consideree comme la plus probable (p), avec une part vraisem- 
blable de difficulte. 


1. Voir C. Jones, Applied Software Measurement, Assuring Productivity and Quality, McGraw-Hill, 
New York, 1991. 
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On prend alors comme estimation la valeur calculee suivante : 
moyenne = (f + F + p)/3 

Souvent, notamment si l’on a un ensemble d’estimations qui se repartissent 
autour d’une valeur la plus probable, on prend une moyenne ponderee : 

moyenne = (f + F + 4p)/6 

La methode de Monte 'Carlo peut etre utilisee avec une methode ascendante. 
Elle necessite d’ avoir, pour chaque activite ou composant, une connaissance fine 
de la repartition des valeurs possibles de la charge. Compte tenu de la quantite 
de calculs, on s’appuie sur un logiciel, dont la logique de fonctionnement est la 
suivante : 

1. Pour chaque activite, on tire au hasard une valeur de charge possible, 
selon la loi de distribution qui lui est attachee. 

2. On fait ensuite la somme de toutes les valeurs obtenues, et on obtient une 
valeur totale du projet ou de la phase. 

3. On recommence n fois les pas 1 et 2. 

4. On prend la moyenne des n valeurs obtenues. 



0,5 2 4 2 7 

Figure 3.12 — Premier tirage dans la methode de Monte-Carlo 


3.10 DEMARCHE GENERALE ^ESTIMATION 

Lorsque Ton doit estimer la charge d’un projet pour lequel les methodes repertoriees 
(evaluation analytique, points fonctionnels) ne peuvent pas s’appliquer, on procede 
de la fagon suivante. 

On recherche tout d’abord a determiner des parametres pertinents, c’est- 
a-dire des elements que l’on pourra denombrer et auxquels on pourra attacher 
une quantite de travail. Pour cela, on effectue un decoupage du projet en taches, 
en distinguant les taches uniques et les taches repetitives. 
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Pour les taches repetitives, on recherche un element qui est proportionnel au 
travail a effectuer, c’est-a-dire un parametre. Soit, par exemple, dans un projet de 
Mise en oeuvre la tache « Former les utilisateurs ». La charge de travail pour 
cette tache qui incombe a l’equipe de projet est proportionnelle au nombre de 
sessions de formation a assurer, chaque session comportant un nombre maximum 
d’utilisateurs. Le parametre est done la session de formation. En fonction du 
nombre d’utilisateurs sur chaque site, on pourra denombrer le nombre de 
sessions a assurer. 

Ensuite, on va determiner le poids des parametres associes aux taches repe- 
titives. On peut utiliser differents moyens, notamment le prototypage et l’echan- 
tillonnage. 

Le prototypage revient a realiser sommairement une des taches repetitives, ce 
qui donne une indication sur l’effort necessaire a ce type de tache. 

L’echan tillonnage consiste, pour chaque type de tache, a faire realiser reel le- 
nient quelques unites, ce qui permet de prendre comme poids la valeur 
moyenne. Dans l’exemple de la formation des utilisateurs, le poids sera la duree 
de la session de formation : on la determinera en formant deux ou trois utilisa- 
teurs pilotes. 

Pour estimer la charge des taches uniques, differents moyens peuvent etre 
utilises. 

On peut rechercher un parametre propre a la tache. Par exemple, pour la 
tache « Construire le seminaire de formation », on peut considerer qu’il y a un 
rapport de proportionnalite a peu pres constant entre le nombre de fonctions 
qu’il faut presenter et la charge de travail necessaire a l’elaboration de cette 
presentation. Le parametre retenu est done la fonction du futur systeme pour 
laquelle il faut preparer une formation. On peut eventuellement classer les fonc- 
tions selon leur degre de complexity et determiner une charge de preparation de 
formation correspondante. 

Sinon, on peut rapprocher cette tache de taches analogues sur des projets 
anterieurs et se baser sur les charges consommees. 

On peut egalement utiliser la methode Delphi, par exemple avec trois ou 
quatre personnes de l’equipe projet. 

Si l’on hesite entre un eventail de valeurs, on peut retenir une approximation 
probabiliste, par exemple la moyenne ponderee d’une estimation que l’on 
ramene a trois points (paragraphe 3.9). 

Cette approche permet ainsi d’elargir les methodes d’estimation des charges a 
une large variete de types de projet autour des systemes d’ information. 
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Plusieurs principes partages par les methodes agiles ont des consequences sur les 
approches d’estimation des charges. 

D’abord, elles font toutes reference a un modele incremental et iteratif, ce qui 
implique imperativement une estimation globale en debut de projet et des esti- 
mations renouvelees a chaque iteration. 

Ensuite, elles donnent une place importante aux utilisateurs durant tout le 
cycle de vie. S’ils sont autorises a demander des modifications fonctionnelles 
jusque dans les phases aval du projet, ils sont tenus d’accompagner au quotidien 
le travail des developpeurs par des indications et des evaluations des differents 
composants du produit en cours de construction. De ce fait, ils sont parties 
prenantes des estimations de charge. 

Enfin, comme le respect d’un delai court est un imperatif, la principale varia- 
ble d’ajustement est le perimetre du projet. Les clients/utilisateurs sont ainsi 
amenes a affecter des priorites aux fonctionnalites et exigences demandees et a 
redefinir le contenu du produit en fonction des estimations. 

Les methodes qui preconisent explicitement une phase de planification gene- 
rale du projet et de construction de son architecture, RAD et DSDM notam- 
ment, suggerent une session participative pour determiner l’enveloppe globale 
du projet. 

Les methodes d’estimation preconisees sont soit une approche basee sur Yamlogie, 
par exemple la methode Delphi, avec de preference des estimations a trois 
points, soit la methode des points de fonction apres une determination generale 
des besoins. 

RAD suggere une productivite de 0,5 jour par point de fonction pour 
l’ensemble du projet. DSDM indique une productivite moyenne de 0,25 jour par 
point de fonction pour la phase de Conception et Construction, et de 0,7 jour 
pour une equipe nouvellement formee qui n’est pas encore habituee a travailler 
ensemble 1 . 

Lorsque Ton entre dans les iterations de developpement, les methodes de types 
analytiques sont privilegiees, c’est-a-dire que Ton s’appuie sur le denombrement 
et la qualification a differents niveaux de granularite. On denombre d’abord les 
fonctionnalites retenues, ensuite les scenarios definissant les fonctionnalites, 
et plus finement les taches necessaires pour realiser les scenarios. 

1. DSDM, version 4.2, Management, Estimating DSDM projects, http://www.dsdm.org/version4/ 

2/public/Estimating.asp 
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Certains peuvent utiliser une estimation parametrique de type COCOMO 
simplffie, c’est-a-dire en nombre de lignes de code, qui ensuite sera converti en 
jours. L’evaluation peut prendre en compte la difficult^ intrinseque de la fonction 
a developper, sa dependance avec d’autres composants, ainsi que la productivite 
des developpeurs. 

XP propose d’utiliser une notion de « point », qui pourrait etre qualffie de 
point de developpement. Chaque scenario est estime en nombre de points, a 
partir des indications foumies par les utilisateurs et d’un rapprochement avec des 
scenarios similaires, anterieurement rencontres dans le projet. 

En debut des iterations de developpement, s’il s’avere particulierement diffi- 
cile de faire une evaluation, notamment par meconnaissance de l’outil de deve- 
loppement, on developpe rapidement un prototype a des fins d’estimation, ce qui 
est appele un spike. 

On peut considerer que cette approche s’apparente a la methode analytique, 
mais il faut toutefois souligner sa dimension dynamique dans la mesure ou : 

• la typologie peut etre redefinie pour chaque projet ; 

• les poids des types de composants peuvent etre reevalues au cours du projet. 

Le passage par une metrique en points evite de faire la confusion entre charge 
et duree. XP parle de « jour- ideal » pour faire reference a des joumees de travail 
completes, c’est-a-dire sans reunion ni autre interruption. Le point permet de 
convertir, par un facteur de 2 ou 3, un jour-ideal en duree. La valeur du point est 
ensuite ajustee en fonction de l’observation de la productivite de l’equipe. 

En effet, apres une premiere iteration de developpement, le nombre de points 
produits par l’equipe est considere comme une bonne mesure de sa productivite. 
XP parle de velocite de l’equipe. Cette valeur correspond a la capacite de produc- 
tion de l’equipe a chaque iteration, les iterations etant en general d’une duree 
fixee. 

La velocite de l’equipe permet de determiner le travail possible et de faire des 
ajustements. En debut de chaque iteration de developpement, l’equipe r assemble 
un nombre de scenarios, les evalue et verffie que leur somme en points corres- 
pond a sa capacite de production, sinon le client doit indiquer ses priorites. Si la 
definition d’un scenario excede la velocite de l’equipe, il faudra le scinder en 
plusieurs scenarios de taille reduite. 

Ensuite, les scenarios sont eclates en taches, qui sont a leur tour estimees et 
reparties entre les developpeurs de fagon a equilibrer leur charge. Si la somme de 
ces estimations elementaires est differente de la valeur retenue en debut d’iteration, 
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Pequipe se retoume vers le client pour ajouter ou retirer un scenario de l’iteration 
de developpement. 

En conclusion, l’estimation des charges apparait, dans un contexte agile, 
avoir un objectif un peu particulier. Bien sur, comme dans tous les projets, l’esti- 
mation initiale sert a avoir une enveloppe et determiner un budget. Mais 
ensuite, il ne s’agit pas de faire une planification detaillee des diffe rentes taches 
et d’en suivre l’avancement. Les estimations permettent principalement d’une 
part de negocier sur des bases tres precises avec les clients/utilisateurs pour qu’ils 
ajustent leurs exigences ; d’autre part de maintenir un rythme de production 
stable dans Pequipe de developpement. 
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Lcs techniques 
de planification des delais 


4.1 ^UTILISATION DE LA PLANIFICATION 


La planification des delais d’un projet comporte deux aspects, l’ordonnancement 
des activites et l’elaboration de l’echeancier, marques par l’utilisation de deux 
techniques complementaires : la technique des graphes et la technique Gantt 
(figure 4.1). 


{(Tache, duree)} 


Ressources 

Contraintes 



Duree minimale 
Latitude entre deux taches 


Calendrier de travail 
Utilisation des ressources 


Fisure 4.1 — Les deux techniques de planification. 


En premier lieu, independamment de toute affectation du travail, on prend 
en compte les caracteristiques de chacun des elements resultant d’un decoupage 
de type WBS (paragraphe 2.2) en general affine. On part done d’une liste d’acti- 
vites avec la duree estimee de chacune d’elles. On commence la planification 
par une reflexion sur les contraintes d! ordonnancement de ces activites et sur les 
possibilites de parallelisme. La technique des graphes d’ ordonnancement permet 
de calculer la duree minimum du projet, ainsi que les temps d’attente eventuels 
entre deux activites. Apres une premiere planification, il est possible d’ajuster le 
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decoupage ou de chercher a assouplir certaines contraintes. En effet, un paralle- 
lisme faible offre peu de marge de manoeuvre dans la repartition du travail. On peut 
egalement utiliser des graphes d’ordonnancement pour traduire plusieurs hypotheses 
de fin de projet souhaitee (figure 4.1). 

Dans un second temps, il s’agit d’etablir un calendrier de travail. La duree mini- 
mum obtenue precedemment est a rapprocher du delai « normal » ou « raisonnable » 
propose par certaines methodes d’estimation des charges (paragraphe 3.7). On 
utilise ici le diagramme de Gantt. Pour cela, il faut faire une hypothese sur les 
ressources dont on disposera et, parfois, prendre en compte les contraintes de 
disponibilite attachees a ces ressources. On peut etablir plusieurs scenarios qui 
correspondent a differentes hypotheses : les diagrammes aident a decider quel est 
le scenario souhaitable (figure 4.1). 

Dans ce chapitre, apres une presentation des techniques des graphes d’ordon- 
nancement et de celle du diagramme de Gantt, nous nous centrerons sur l’etablisse- 
ment d’une planification operationnelle. Nous terminerons sur la prise en compte 
de l’incertitude, via une utilisation probabiliste du graphe d’ordonnancement. 

4.2 LES GRAPHES D’ORDONNANCEMENT 

Il existe deux formalismes de representation de l’ordonnancement des activites : 
la methode des antecedents et la methode du diagramme fleche. 

Dans le graphe de la methode des antecedents (figure 4.2), les activites figu- 
rent sur les rectangles, les fleches ne representant que les liens. Les ronds repre- 
sentent des jalons, c’est-a-dire des activites de duree nulle. 



Figure 4.2 — Graphe de la methode des antecedents. 


Dans le graphe de la methode du diagramme fleche (figure 4.3), les activites 
figurent sur les fleches, les ronds represented des evenements appeles jalons. 
Ceux-ci n’ont pas de duree. Pour traduire de fapon correcte les contraintes 
d’enchainement, on est parfois amene a introduire des activites fictives, repre- 
sentees par des fleches en pointilles. 

Ces deux notations sont equivalentes. Dans cet ouvrage, nous utilisons le 
formalisme du graphe des antecedents, qui est plus simple et qui est retenu par 
la majorite des progiciels de planification. Ce type de reseau peut etre utilise a 
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Figure 4.3 — Graphe de la methode du diagramme fleche. 


differentes mailles de decomposition du projet. Dans la suite, nous employons le 
terme « tache » de fapon generique, celle-ci pouvant aussi bien etre une tache 
elementaire, qu’une activite ou meme une phase. 

Soulignons qu’il y a eu ces demieres annees un changement de vocabulaire : ce 
graphe a longtemps ete appele reseau PERT (comme nous l’avons fait dans de prece- 
dentes editions de cet ouvrage). Aujourd’hui, lorsque Ton emploie le terme PERT, 
c’est souvent pour faire reference au PERT probabiliste expose en fin de ce chapitre. 
De son cote, 1’IPMA ainsi que le logiciel MS Project, dans sa version 2003, utilisent 
le terme organigramme des taches, OT, pour designer le graphe des antecedents. 


4.3 LES TYPES DE LIENS 

Les liens entre les taches representent des contraintes provenant de la nature des 
taches elles-memes. II existe quatre types de liens : le lien fin-debut, le lien fin- 
fin, le lien debut-debut, le lien debut-fin (figure 4-4). 


Fin-debut 

Fin-fin 

Debut-debut 

Debut-fin 


I +/-n jours 


+/- n jours 


. +/-n jours 


Figure 4.4 — Les types de lien. 
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Le lien fin-debut est le plus courant : la tache A doit etre terminee pour que la 
tache B puisse commencer. La tache A est le predecesseur de la tache B. La tache 
B est le successeur de la tache A. On dit parfois que A est antecedente et B subse- 
quente. 

Par exemple (figure 4.5), la tache de Programmation doit etre terminee pour 
que la tache de Test puisse commencer. 


Programmation ► Test 


Figure 4.5 — Lien fin-debut. 

Le lien peut etre caracterise par un delai, exprime en jours. Si le delai est 
negatif (- n jours), on parle d’une avance 1 . Id avance peut etre exprimee enpourcen - 
tage de la charge restante (- x %) . 

Par exemple (figure 4.6), la tache de Test peut commencer 10 jours avant la fin 
de la tache de Programmation (-10 jours), pour preparer l’environnement de test. 


Programmation I 10 jours I 


Figure 4.6 — Lien fin-debut avec avance. 

Si le delai est positif (+ n jours), on parle d’un retard 2 . 

Par exemple (figure 4.7), la tache de Prise en compte des suggestions peut 
commencer 10 jours apres la tache d’Installation du prototype. 


Installation 

+ 10 jours 

Prise en compte 

du prototype 


des suggestions 


Figure 4.7 — Lien fin-debut avec retard. 


Le lien fin-fin signifie : c’est la fin de la tache A qui commande la fin de la 
tache B. La tache B ne peut s’arreter que lorsque A s’arrete. 

Par exemple (figure 4.8), la tache d’Encadrement de programmation dure 
tant que la tache de Programmation n’est pas terminee. 


1. Lead en anglais. 

2. Lag en anglais. 
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Programmation 


| Encadrement de programmation | 


Figure 4.8 — Lien fin-fin. 

Ce lien peut etre egalement caracterise par une avance ou un retard. 

Par exemple (figure 4.9), la tache d’Encadrement de mise en oeuvre se termine 
20 jours apres la fin de la tache de Mise en oeuvre d’un logiciel, pour assurer une 
aide au demarrage. 


Mise en oeuvre 


Encadrement de mise en oeuvre 


r + 20 jours 


Figure 4.9 — Lien fin-fin avec retard. 


Le lien debut-debut signifie : c’est le debut de la tache A qui declenche le debut 
de la tache B. B doit obligatoirement commencer quand A commence. 

Par exemple (figure 4.10), la tache de Modelisation doit commencer en 
meme temps que la tache Interviews. 


Interviews 


Modelisation 


Figure 4.10 — Lien debut-debut. 


Ce lien peut etre egalement caracterise par une avance ou un retard. 

Par exemple (figure 4.11), la tache Preparation de l’environnement techni- 
que doit commencer 10 jours avant le debut de la tache de Programmation et la 
tache d’ Alimentation du dictionnaire de donnees doit commencer 10 jours 
apres le debut de la tache de Modelisation. 
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Programmation 


Modelisation 

, - fO jours , 

, + 10 jours 

Preparation environ- 
nement technique 


Aiimentation 
du dictionnaire 


Figure 4.1 1 — Liens debut-debut avec delai. 

Le lien debut-fin signifie : c’est le debut de la tache A qui marque la fin de la 
tache B. La tache B ne peut s’arreter tant qu’A n’a pas commence. 



Figure 4.12 — Lien debut-fin. 


Par exemple (figure 4.12), le debut de la tache Formation de l’equipe marque 
la fin de la tache Support technique. 

Ce lien peut etre egalement caracterise par une avance ou un retard. 

Par exemple (figure 4.13), la tache Exploitation de l’ancien logiciel s’arretera 
15 jours apres le debut de la tache Exploitation du nouveau logiciel. 



Figure 4.13 — Lien debut-fin avec retard. 


4.4 LA METHODE DU CHEMIN CRITIQUE 

L’ analyse d’un graphe s’effectue avec une methode appelee la methode du chemin 
critique 1 , car elle permet de mettre en evidence des chemins qui component des 
taches critiques, dans le sens ou elles vont retarder la fin du projet si elles sont elles- 
memes en retard. 


1. Ou CPM : Critical Path Method. 


4.4. La methode du chemin critique 
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Pour mettre en evidence ce chemin critique, on calcule les parametres cles 
attaches a chaque tache du graphe. 

Pour chacune, on veut obtenir : 

• les dates au plus tot : Debut au plus tot et Fin au plus tot ; 

• les dates au plus tard : Debut au plus tard et Fin au plus tard 1 ; 

• les marges 2 : marge totale et marge libre. 

La signification des dates au plus tot (D+tot, F+tot) et au plus tard (D+tard, 
F+tard) est la suivante. 

Compte tenu des contraintes d’enchainement, de la duree des taches et de la 
date de debut de projet, la tache T, ne peut pas commencer avant D+tot et ne 
peut se terminer avant F+tot. 

Par ailleurs, compte tenu des contraintes d’enchainement, de la duree des 
taches et de la date de fin de projet, elle ne doit pas se terminer apres F+tard sans 
mettre le projet en retard. De meme, elle ne doit pas commencer apres D+tard, 
sinon la date de fin du projet serait depassee. 

Pour calculer ces dates, nous devons avoir la duree d ; de chaque tache T,. On 
va supposer dans un premier temps qu’il n’y a que des liens de type fin-debut. 

Pour calculer les dates au plus tot de chacune des taches, on va faire l’hypo- 
these d’une date de debut de projet (t 0 ) et on va parcourir le graphe vers 1’ avant 
en respectant les liens. 

Si la tache T, se situe en debut de projet, la date de debut au plus tot est t 0 . Sa 
date de fin au plus tot est (t 0 + d, - 1). 

D+tot (Tj) = t 0 
F+tot (Tj) = t 0 + dj - 1 


Par exemple, en supposant tous les jours ouvrables (figure 4.14) : 


1. En anglais : Early start et 

2. Slack en anglais. 


2 avril, 6 avrif 



Figure 4.14 — Dates au plus tot. 


Early finish, Late 


Late finish. 
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Si la tache Tj ne se situe pas en debut de projet, elle a des predecesseurs. Sa 
date de debut au plus tot est egale a la plus grande des dates de fin au plus tot de 
tous ses predecesseurs plus une periode. Sa date de fin au plus tot est obtenue en 
ajoutant la duree de la tache moins une periode. 

D+tot (Tj) = sup {F+tot (predecesseurs)} + 1 
F+tot (T t ) = D+tot (T;) + dj - 1 


Par exemple (figure 4.15), en supposant tous les jours ouvrables : 


2 avril, 6 avril 



Figure 4.15 — Dates au plus tot avec predecesseurs. 


Pour calculer les dates au plus tard de chacune des taches, on va faire l’hypo' 
these d’une date de fin de projet et on va parcourir le graphe vers l’arriere en 
respectant les liens. 

Soit t f la date de fin de projet. Si la tache T, se situe en fin de projet, la date de 
fin au plus tard est tf. Sa date de debut au plus tard est (t f - d, + 1). 

F+tard (Tj) = tf 
D+tard (TJ = t f -di+ 1 


Par exemple (figure 4.16), en supposant que le projet se termine le 15 decembre 
et que tous les jours sont ouvrables : 

11 decembre, 15 decembre 
K 

d = 5 jours 

T f = 15 decembre 



Figure 4.16 — Dates au plus tard. 
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Si la tache T : ne se situe pas en fin de projet, elle a des successeurs. Sa date de 
fin au plus tard est egale a la plus petite des dates de debut au plus tard de tous ses 
successeurs moins 1 . Sa date de debut au plus tard est obtenue en soustrayant la 
duree de la tache et en ajoutant 1. 

F+tard (T,) = inf {D+tard (successeurs)} - 1 
D+tard (T f ) = F+tard (T,) - + 1 


Par exemple, en supposant tous les jours ouvrables (figure 4.17) : 



Figure 4.17 — Dates au plus tard avec successeurs. 


S’il y a d’autres types de liens, c’est la tache maitre qui impose les dates (debut 
et/ou fin) de la tache dependante, aussi bien pour les dates au plus tot que pour 
les dates au plus tard. 

Par exemple, considerant que les dates attachees a chaque tache se lisent 
dans l’ordre : 

Debut au plus tot, fin au plus tot 
Debut au plus tard, fin au plus tard 

et que Ton mesure le temps en semaines, on a les parametres portes sur la figure 4.18. 


20 , 22 20 , 22 

2f, 23 21,23 


20, 22 
21,23 


C 

3 semaines 

20 , .. 
21 , .. 

D 


C 

3 semaines 



Figure 4.18 — Dates cles avec liens particuliers. 
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La marge attachee a chaque tache est la difference entre date au plus tard (TJ 
et date au plus tot (TJ. En l’absence de liens autres que des liens fin-debut, elle 
peut etre calculee indifferemment sur les dates de debut ou sur les dates de fin. 
Sinon, on peut avoir deux marges differentes sur une tache, l’une attachee au 
debut de la tache, l’autre attachee a la fin de la tache. La marge represente la lati- 
tude dont on dispose quand on elabore le planning. 

On peut faire des simulations avec differentes dates de fin du projet. La marge 
ne doit jamais etre negative : sinon, il faut revoir le graphe, en modifiant la tache 
(eclatement de la tache en deux pour reduire la duree de la tache et augmenter 
le parallelisme), en levant certaines contraintes (decouplement de taches) ou en 
modifiant la date de fin du projet visee. 

La marge, telle que definie ci-dessus, est parfois appelee marge totale, lorsque 
l’on veut l’opposer a une marge plus reduite appelee marge libre. On dispose d’une 
marge libre ml sur Tj si on peut planifier la T, a la date (D+tot (TJ + ml) sans que 
cela ait de consequence sur ses successeurs (c’est-a-dire qu’on peut toujours les 
planifier au plus tot). 


Marge libre (TJ = inf {D+tot (successeurs)} - F+tot (TJ - 1 


Le schema de la figure 4.19 illustre la difference entre marge libre et marge 
totale. La tache A dure deux periodes : sa planification au plus tot se fait aux 
periodes 1 et 2, et sa planification au plus tard aux periodes 5 et 6. La marge 
totale de A est done de 4. La tache B commence au plus tot en periode 6. Si Ton 
planifie la tache A aux periodes 4 et 5, cela est sans consequence sur les choix de 
la planification pour la tache B. En revanche, si l’on fait une planification en 
utilisant la marge totale, c’est-a-dire aux periodes 5 et 6, on ne pourra planifier la 
tache B qu’a partir de la periode 7. La marge libre de A est done de 3. 



1 2 

3 4 5 

6 

7 8 9 

A 

D+tot F+tot 

D+tard 

F+tard 




Marge totale = 4 




Marge libre = 3 



B 



D+tot 


Figure 4.19 — Chemin critique. 


Les marges (totale et libre) figurent sur le reseau de la figure 4.20. 

Le chemin critique est le chemin du graphe sur lequel les marges totales sont 
nulles. La marge libre de toutes les taches du chemin critique est done nulle. 


4.5. Le diagramme de Gantt 
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S’il n’y a que des liens fin-debut, le chemin critique est le chemin le plus 
long : il est done a surveiller tout particulierement. 



S’il y a d’autres liens que des liens fin-debut dans un reseau, le chemin critique 
peut ne pas etre complet, e’est-a-dire ne pas parcourir le graphe du debut a la fin. 

C’est egalement le cas si l’on a des contraintes temporelles, e’est-a-dire des 
dates imposees (debut impose ou fin imposee) pour certaines taches. Ce point 
sera illustre au chapitre 11 (paragraphe 11.9). 


4.5 LE DIAGRAMME DE GANTT 

Le graphe des antecedents permet de faire apparaitre les possibilites de parallelisme 
dans l’execution des taches et donne les dates de fin du projet possibles en dehors 
des contraintes de ressources. Pour passer a un planning (calendrier du projet), il 
faut faire des hypotheses de ressources et affecter les taches a des personnes ou a 
des profils de personnes. On pourra faire plusieurs simulations selon la taille de 
l’equipe envisagee. On prend egalement en compte les contraintes de calendrier 
(jours non ouvrables, jours feries...). 

On utilise, pour representer le planning, le diagramme de Gantt, qui se cons- 
tant de la fagon suivante : 

• en abscisse, on a l’axe du temps ; 

• en ordonnee, on peut avoir soit les taches, soit les personnes affectees aux 
taches. 

Selon que l’on utilise ou non les marges pour effectuer la planification, on 
parlera de planification au plus tot ou de planification au plus tard. 
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Le diagramme de Gantt, qui porte le nom de son concepteur, a ete elabore au 
debut du XX e siecle pour representer de fagon graphique la repartition du travail en 
atelier. C’est probablement la technique de gestion de projet la plus largement utilisee. 

Voici des exemples de planning a partir du reseau ci-dessus (figure 4.20). 

• Planification au plus tot : on planifie les taches en s’appuyant sur les dates au 
plus tot (figure 4.21). On utilise deux personnes : ressource 1 (Rl) et 
ressource 2 (R2). R2 doit attendre pendant 9 periodes, car la tache C ne peut 
demarrer avant la fin de la tache B. Les parties grisees representent la marge. 


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 



Figure 4.21 — Diagramme de Gantt avec planification au plus tot. 



Figure 4.22 — Diagramme de Gantt avec planification au plus tard. 


4.6. La planification operationnelle 
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• Planification au plus tard : on planifie les taches en s’appuyant sur les dates 
au plus tard (figure 4.22). On utilise deux personnes : ressource 1 (Rl) et 
ressource 2 (R2). Aucune tache ne peut prendre de retard, sinon le projet 
ne pourra s’achever a la date visee. 

• Amelioration du diagramme au plus tot de la figure 4.21 : on utilise trois 
ressources, Rl, R2 et R3 ; et on place la tache A de fagon a eviter une 
attente pour R3 (figure 4.23). 



Figure 4.23 — Diagramme de Gantt avec planification amelioree. 


4.6 LA PLANIFICATION OPERATIONNELLE 

4.6.1 La prise en compte des contraintes 

Pour etablir un diagramme Gantt en vue d’une planification operationnelle, on 
doit prendre en compte toutes les contraintes, en commengant par celles qui 
sont les plus fortes et en terminant par les taches sur lesquelles on a la latitude la 
plus elevee. Souvent, on cherche une planification satisfaisante, qui, souvent, 
n’est pas la seule possible. 

On distingue plusieurs types de contraintes : 

• Les contraintes de liens entre taches ont ete mises en evidence sur le graphe 
des antecedents, et en particulier le chemin critique. Si l’on veut terminer 
dans le delai minimum, on planifie en premier les taches qui sont sur le 
chemin critique. On planifiera ensuite les taches qui sont bees aux taches 
du chemin critique par des liens du type debut-debut, fin-fin ou debut-fin, et 
enfin on placera les taches qui sont des predecesseurs des taches critiques. 
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• Les contrcdntes temporelles, c’est-a-dire les dates imposees pour une ou plusieurs 
taches, figurent egalement sur le graphe des antecedents. Ce sont des 
contraintes tres fortes, puisqu’elles ne laissent pas de choix. 

• Les contraintes liees a la disponibilite des ressources correspondent soit a une 
ressource specialisee, seule a meme d’effectuer certaines des taches du 
projet, soit a une penurie de ressources. Dans les deux cas, cela peut 
conduire a revoir le graphe pour supprimer des possibilites de parallelisme 
que Ton n’est pas a meme d’exploiter. Par exemple, si une personne R1 se 
voit confier deux taches A et B pouvant etre faites en parallele, il faudra 
choisir dans quel ordre ces taches seront effectuees. Cela correspond a la 
technique du lissage exposee au paragraphe 4.6.4. 

• Les contraintes d’ exclusion indiquent que des taches independantes ne 
doivent pas etre planifiees simultanement, souvent pour des raisons de 
securite. Ces contraintes sont assez rares dans notre domaine. On peut 
donner comme exemple les deux taches suivantes : Tests volumetriques et 
Recette fonctionnelle. Si elles s’effectuent sur la meme machine de test, 
on risque de penaliser la recette et d’indisposer le client. 

4.6.2 [.'utilisation des marges 

Pour limiter les risques de retard provoque par des aleas, le chef de projet a 
souvent tendance a gonfler la duree des taches, c’est-a-dire a introduce de la 
marge cachee un peu partout dans la planification. E. Goldratt 1 appelle cette 
marge un tampon (buffer) et conseille de ne pas repartir les tampons sur toutes les 
taches, mais de le faire judicieusement pour qu’ils contribuent effectivement a la 
maitrise des delais. Sinon, ces marges seront systematiquement consommees 
sans amelioration de la performance du projet. 

II fait en particulier trois recommandations. 

D’abord, il est souhaitable de prevoir un tampon en fin de projet pour absor- 
ber les fluctuations du chemin critique. 

Ensuite, il est prudent de placer un tampon en fin des taches qui sont des 
predecesseurs des taches du chemin critique. En effet, certaines de ces taches 
peuvent presenter des risques de derapages, dont les consequences toucheront le 


1. E. Goldratt est l’auteur d’une approche de gestion de production basee sur l’identification des 
contraintes dominantes et notamment des goulets d’etranglement, dont la prise en compte 
permet de limiter les stocks et de reduire le cycle de production. Cette approche decrite dans 
The Goal (1984) a ete transposee a la planification de projet sous le nom de CCPM, critical 
chain project management, gestion de projet par la chaine critique. Pour plus de details, voir le 
dossier paru dans La Cible n° 80 (la revue de l’AFITEP) de juin 2000. 
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chemin critique. Si le tampon n’est pas entierement consomme, cela pourra 
eventuellement permettre d’anticiper sur le demarrage de la tache critique. 

Enfin, si une ressource doit intervenir sur une tache critique et si elle ne 
travaille pas deja sur le projet, il est bon de lui notifier son intervention quelques 
jours avant, pour qu’elle ne prenne aucun retard au demarrage de la tache critique. 

Le tampon se presente comme une tache Active, liee a la tache qu’elle doit 
proteger, comme predecesseur ou comme successeur. 

4.6.3 Le nivellement 

La technique du nivellement consiste a maintenir le nombre de personnes 
travaillant simultanement sur le projet en dessous d’une certaine limite. On va 
done, en general, augmenter la duree du projet. Le nivellement vise l’ensemble 
des ressources du projet. 

Plusieurs raisons peuvent conduire a utiliser cette technique. Le nivellement 
evite d’avoir une taille d’equipe de projet trop importante par rapport a la duree 
totale du projet. Une premiere hypothese de planification qui exploite au maxi- 
mum le parallelisme peut conduire a une taille d’equipe risquant de generer des 
surcharges de coordination. La disponibilite des ressources (personnes, materiel, 
locaux...) peut etre telle que Ton doit renoncer a utiliser toutes les possibilites 
d’executer des taches en parallele, telles qu’elles figurent sur le graphe des ante- 
cedents. Le nivellement permet enfin d’etaler dans le temps les depenses liees 
au projet. 

Soit par exemple le projet structure en taches selon le reseau de la figure 4.24. 



Le graphe fait apparaitre trois chemins en parallele. On va done faire une 
premiere planification avec trois ressources (figure 4.25). 
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1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 


Figure 4.25 — Diagramme de Gantt avant nivellement. 


Supposons qu’on veuille limiter la taille de l’equipe a deux personnes : on va 
done niveler le diagramme, en allongeant la duree du projet (figure 4.26). On en 
profite pour etaler la montee en charge, en integrant les deux ressources non pas 
simultanement mais successivement : R2 n’arrive sur le projet qu’en fin de 
periode 8, quand R1 acheve sa premiere tache. 


9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 


Figure 4.26 — Diagramme de Gantt apres nivellement. 
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4.6.4 Le Hssage 

La technique du lissage consiste a repartir pour chaque ressource sa charge de 
travail, de telle fagon qu’elle ne se trouve a aucun moment en surcharge ou en 
sous-charge. On va jouer sur les marges pour decaler les taches. Contrairement a 
ce qui se passe quand on cherche a niveler, on s’interesse ici a la repartition de la 
charge affectee a chaque ressource. Une operation de lissage peut conduire a 
allonger les delais. 
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Figure 4.27 — Diagramme de Gantt apres lissage. 


Les raisons du lissage sont le plus souvent des contraintes liees a l’utilisation 
des personnes. Parfois, on peut vouloir lisser a cause de la disponibilite reduite 
d’un materiel. 

Nous avons repris le meme exemple que ci-dessus (figure 4.25) et nous avons 
fait une operation de lissage (figure 4.27). 

On a suppose que la ressource R1 ne pouvait travailler qu’a mi-temps. Le 
diagramme de la figure 4.25 etait done en surcharge pour Rl. Nous avons du 
replanifier en doublant la duree des taches affectees a Rl. On a alors decide de 
reaffecter la tache H, situee sur le chemin critique, a R2. On a planifie la tache B 
au plus tot, car elle etait maintenant sur le chemin critique. Par contre, on a 
utilise les marges des taches affectees a R3 afin d’etaler la montee en charge du 
projet. 
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4.7 LE PERT PROBABILISTE 

Cette technique, qui s’appuie sur le graphe des antecedents, permet d’inclure 
dans la planification le risque et l’incertitude attaches a chaque tache et d’en 
deduire une duree du projet assortie d’un niveau de probabilite. La duree de chaque 
tache peut etre consideree comme une variable aleatoire, c’est-a-dire que Ton 
peut faire plusieurs estimations (plus ou moins probables) de la duree de la tache. 
Alors, la duree de tout chemin dans le graphe PERT ( Program Evaluation and 
Review Technique ) est egalement consideree une variable aleatoire, puisque c’est 
une somme de variables aleatoires. 

Sous reserve des conditions suivantes : 

• un nombre suffisamment eleve de taches (minimum 4 sur le chemin) ; 

• un ordre de grandeur semblable pour toutes les taches ; 

• l’independance entre les durees des taches ; 

la duree probable du chemin obeit a une loi de distribution proche de la loi 
normale (Laplace-Gauss), dont la representation graphique est la courbe en 
cloche dite de Gauss. 

Le calcul des parametres du PERT probabiliste se fait en trois etapes : 

La premiere etape consiste a determiner la loi de probabilite attachee a 
chaque tache. En pratique on retient souvent une loi de distribution Beta, c’est- 
a-dire qu’on est capable de donner trois estimations : 

1. t opt = estimation optimiste de la duree, c’est le temps minimal possible, si 
tout se deroule mieux que prevu ; 

2. tp es = estimation pessimiste de la duree, c’est le temps maximal possible, si 
tout se deroule au plus mal (hors catastrophe) ; 

3. t vrai = estimation vraisemblable de la duree, c’est la valeur que l’on donne- 
rait si on devait n’en donner qu’une seule. 

La deuxieme etape consiste a calculer trois valeurs pour chaque tache i : 

• sa duree probable t^O) : c’est une moyenne statistique, c’est le temps 
moyen de la tache si elle etait repetee un grand nombre de fois ; 

• sa variance Vm et son ecart-type e (l) : plus les estimations optimistes et pessi- 
mistes sont eloignees, plus elles presentent d’incertitude. C’est la variance 
qui mesure cette incertitude. Si elle est faible, l’estimation de la duree 
probable de la tache sera assez precise. 

t oPt (i) + 4t vrai (i) + t pes (i) 
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tpesCO - tpptiO 
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V G) = e d) 2 

La troisieme etape consiste a calculer pour chaque chemin : 

• sa duree estimee D est ; 

• sa variance estimee V est ; 

• son ecart-type estime E est 


D est = Sommelt^dj} pour toutes les taches i du chemin 
V est = Somme { e m 2 } pour toutes les taches i du chemin 

E est = (V es t)^ 2 

Comme la duree du chemin obeit a une loi normale, on peut utiliser la table de 
Gauss (figure 4.28) pour obtenir la duree D p du chemin avec une probability p : 

D p = D est + G(p) E est 

La duree estimee du projet est probable a 50 % (car G(50) = 0). 


Probability = p 

G(p) 

Probability = p 

G(p) 

Probability = p 

G(p) 

99,9 

3,00 

90 

1,28 

42,1 

-0,2 
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2,31 

89,1 

1,23 
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85,1 

1,04 

27,4 
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97 

1,88 

80,2 

0,85 

21,2 
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96 

1,75 

75,2 

0,68 

15,9 

- 1 

95 

1,65 

70,2 

0,53 

11,5 

- 1,2 

94,1 

1,56 

65,2 

0,39 

8,1 

- 1,4 

93,1 

1,48 

60,3 

0,26 

5,5 

-1,6 

92,1 

1,41 

55,2 

0,13 

3,6 

-1,8 

91 

1,34 

50 

0,00 

2,3 

-2 


Figure 4.28 — Extrait de la table de Gauss. 


Soit par exemple un chemin de duree estime D est = 100 et d’ecart-type estime 
E cst = 15. On peut en deduire soit une duree probable pour une probability 
donnee, soit une probability d’achevement dans un delai donne. 
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Ainsi, 

La duree probable a 90 % est : 

D90 = 100 + G(90) x 15 

D90 = 100 + 1,28 x 15 = 119 jours. 

La duree probable a 60 % est : 

D60 = 100 + G(60) x 15 

D60 = 100 + 0,26 x 15 = 104 jours. 

La probability de terminer en 80 jours est : 

80 = 100 + G(p) x 15 
d’ou:G(p) = -20/15 = -1,33 
d’ou : la probability est comprise entre 9 et 10 %. 

On peut donner une mesure du risque par le ratio : 

R = l P es ~ to P c 
tpes 

et considerer que : 

R < 0,25 : risque faible 
0,25 < R < 0,5 : risque moyen 
R > 0,5 : risque fort 

Le PERT probabiliste est interessant pour les projets a forte incertitude, parti- 
culierement sur le chemin critique, ainsi que sur les chemins ayant les plus forts 
risques. 

Si l’incertitude est faible, la difference [t pes - t opt ] est faible par rapport a la 
duree estimee de la tache. Dans ce cas, les variances des taches seront faibles, de 
meme que la variance du chemin, done E est . On n’a done pas besoin d’un PERT 
probabiliste. On peut se contenter d’un graphe de la methode des antecedents. 


4.8 LA PLANIFICATION DES DELAIS DANS LES METHODES AGILES 

Les techniques de planification sont probablement, de toutes les techniques, 
celles qui ont ete les plus utilisees dans les projets. En particulier, le diagramme 
de Gantt, avec plus ou moins de sophistication, est connu de tous les chefs de 
projet. 
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Cependant, les methodes agiles presenters trois principales particularites 
dans la planification des delais : la negociation des delais, la planification selec- 
tive et l’utilisation de la technique de la timebox. 

1. Tout d’abord, au niveau du cycle de vie complet du projet, la date de livrai- 
son finale ainsi que celle des principaux jalons — les iterations de livraison 
dans XP presentees au § 2.8.3 — sont negociees avec le client/commanditaire. 
Le nombre et la duree des iterations de developpement en dependent. Le 
respect de ces dates est ensuite imperatif. Cela entraine souvent l’utilisation 
d’un tampon (cf. § 4.6.2) avant ces echeances-cles. 

2. Ensuite, les taches confiees aux developpeurs dans une iteration de develop- 
pement ne font pas l’objet d’une planification en bonne et due forme. II est 
plutot considere que la realisation de ces taches dans la duree planifiee du 
cycle releve de l’engagement de l’equipe. Les membres, selon le Manifeste 
Agile, sont incites a reflechir regulierement sur de possibles augmentations 
de l’efficacite collective et a modifier leurs comportements en consequence. 

Cette planification selective, laissant une place a l’auto-organisation, est bien 
representee par le schema de deroulement de la methode SCRUM donne 
par K. Schwaber 1 (figure 4.29) dont le cycle de vie a ete presente au § 2.8.4. 
En dehors des iterations (les sprints), le travail peut et doit etre planifie rigou- 
reusement. En revanche, compte tenu a la fois de la duree des iterations et 
de l’imperatif d’ajustement, il serait lourd et inutilement contraignant de faire 
une planification detaillee de toutes les taches. Au chapitre 7, on indique les 
moyens utilises pour piloter l’avancement. 



Figure 4.29 — Phases soumises a la planification dans SCRUM selon K. Schwaber. 


1. Ken Schwaber, SCRUM Development process, http://jeffsutherland.com/oopsla/schwapub.pdf 
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3. Enfin, les iterations sont soumises a la technique de la timebox. 

La maitrise du delai requiert la fixation d’une date limite, surtout lorsque le 
projet comporte une marge d’indetermination elevee sur le resultat a fournir. 
Le principe de la technique timebox est d’etablir une enveloppe temps, de 
duree fixe et limitee, qui ne doit etre depassee sous aucun pretexte, pour 
eviter des glissements dont on ne maitriserait pas l’ampleur. On peut la consi- 
derer comme une contrepartie a la possibility offerte aux utilisateurs de 
demander des changements tout au long du projet. En effet, si l’enveloppe 
temps doit etre imperativement respectee, cela impose des ajustements nego- 
cies sur le perimetre fonctionnel. Certaines fonctions ou ameliorations sont 
done abandonnees ou repoussees dans une version ulterieure. 

Le principe de la timebox fut elabore apres une experience remarquee dans 
l’entreprise chimique DuPont de Nemours en 1989 1 . La Division Fibres etait 
en train de passer a un systeme hautement automatise, ce qui obligeait a 
reecrire toutes les applications de gestion de production, soit 100 000 lignes 
de code. Le projet avait ete planifie sur deux ans par la Direction Informa- 
tique, alors que la Direction generale voulait que le changement se fasse en 
moins de six mois. Apres discussion entre Direction Informatique et Direc- 
tion de Production, on convint de construire un systeme robuste, mais 
sommaire, qui evoluerait ensuite par versions. Toutes les applications devai- 
ent etre developpees en 90 jours. 

La reussite de cette pratique, transformee en technique sous le nom de time- 
box, conduisit d’autres entreprises a l’utiliser. La plupart des methodes agiles 
l’ont adoptee pour leurs phases de Construction. 

Les durees sont calees sur la capacite de l’esprit humain a se representer 
l’echeance et d’une certaine fagon a declencher interieurement un compte a 
rebours. C’est pourquoi l’enveloppe temps allouee est en general comprise 
entre deux et quatre mois, le nombre recommande d’ iterations variant entre 
trois et neuf, chacune durant entre deux et trois semaines. 


1. J. Martin en fait l’historique dans Rapid Application Development, Macmillan, 1991. 
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d’un projet 


Nous allons dans ce chapitre nous interesser plus particulierement a la dimension 
humaine et relationnelle des projets : nous examinerons d’abord les bases de l’orga- 
nisation du travail, c’est-a-dire la division et la coordination du travail ; nous trai- 
terons ensuite de la participation des utilisateurs ; puis nous preciserons le 
role du chef de projet, particulierement dans le management d’equipe et la gestion 
des conflits ; nous donnerons des elements sur la gestion du changement lie a 
un nouveau systeme d’information. Nous terminerons par les particularites du 
management des ressources humaines et de la communication dans un contexte 
de methode agile. 


5.1 ^ORGANISATION DU TRAVAIL 

5.1.1 La division et la repartition du travail 

Tout projet d’une certaine taille fait l’objet d’un decoupage en travaux a execu- 
ter : ce point a ete developpe au chapitre 2. Les taches ainsi identifies peuvent 
parfois etre executees simultanement : ces possibilites sont mises en evidence par 
le graphe des antecedents et le diagramme de Gantt, presentes au chapitre 4. 

La repartition du travail entre des personnes differentes vise plusieurs objec- 
tifs. Elle permet de raccourcir la duree du projet. Quand on developpe un systeme 
d’information, le delai est souvent critique. Si, par exemple, la regimentation 
bancaire autorise le lancement d’un nouveau produit d’epargne, que Ton prevoit 
attractif, il faut pouvoir disposer au jour j du systeme d’information permettant 
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la gestion et la souscription : les banques qui se positionnent les premieres 
emporteront la plus grande part du marche. La repartition autorise le partage de 
competences specialises. Certaines personnes peuvent intervenir ponctuelle- 
ment ou partiellement sur plusieurs projets. Elle repartit les risques lies aux 
personnes. En cas de defaillance d’un acteur, il faut pouvoir poursuivre le projet. 
C’est plus facile si toute la connaissance du projet n’est pas concentree sur la 
personne defaillante. Enfin, la repartition garantit une diversite de points de 
vue, chaque acteur apportant sa propre ouverture. 

Les inconvenients de la division du travail dans le cadre d’un projet ne sont pas 
aussi graves que ceux qui ont ete abondamment analyses pour les travaux repetitifs 
de l’organisation taylorienne. La participation a un projet, en effet, n’est jamais 
identique a la precedente : ennui et demotivation sont done moins a craindre. 

Quels sont les criteres de repartition du travail ? Globalement, on retrouve 
les deux principes de base : specialisation ou polyvalence. La specialisation 
consiste a confier a une meme personne des taches d’une seule nature. Par exem- 
pie, Elaboration des modeles, les etudes techniques, la constitution d’un jeu 
d’essai, l’ecriture de programmes... On augmente ainsi la productivity. On 
limite les risques lies a la defaillance d’un acteur : le remplacement sur des taches 
bien circonscrites est generalement plus aise. La polyvalence consiste a confier a 
une seule personne un sous-ensemble coherent de taches diverses, conduisant 
souvent a l’elaboration d’un produit livrable. C’est ce que l’on appelle parfois un 
« lot ». La polyvalence favorise l’apprentissage des acteurs en elargissant leur 
palette de competences. Elle minimise la charge de mise au courant du dossier. 
Elle reduit le besoin de coordination, puisque le lot entier est pris en main par 
une seule personne. 

Les choix de repartition s’appuient egalement sur les caracteristiques propres 
aux individus : experiences, souhaits, disponibilites... 


5.1.2 La coordination du travail 

La division et la repartition du travail generent un besoin de coordination. Le 
travail peut etre reparti dans le temps : il faut alors coordonner les phases et 
etapes successives. A un moment donne, il faut eviter redondances ou incohe- 
rences entre plusieurs sous-projets ou a l’interieur d’un projet entre les differen- 
tes personnes de l’equipe. 

Le but de la coordination est d’integrer les differen tes activites et les diffe- 
rents participants pour atteindre les objectifs du projet global. 

Il y a deux sortes de coordination, personnelle ou impersonnelle, qui peuvent 
chacune prendre differentes formes . 1 


1. H. Mintzberg, Structure et dynamique des organisations, ed. Organisation, 1982. 
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La coordination personnelle repose sur les personnes : 

On parle d’ajustements mutuels quand la coordination est assuree par des 
echanges informels lors de contacts directs entre les individus, par exemple, des 
demandes ponctuelles d’information entre concepteurs. 

On parle de supervision directe lorsqu’une personne assure la liaison : il s’agit 
d’une fonction d’encadrement qui revient souvent au chef de projet. La supervi- 
sion directe vise generalement a controler l’avancement des travaux et a s’assurer 
de leur convergence et coherence. 

La coordination impersonnelle repose sur un dispositif : 

La standardisation des procedes consiste a imposer les memes precedes a tous 
pour reduire les risques d’incoherence, faciliter l’integration et la comprehension 
mutuelle. L’utilisation de methodes communes (techniques de modelisation, 
modele de developpement, demarche d’ evaluation des charges) est un exemple 
de standardisation des procedes. 

La standardisation des resultats consiste a etablir des normes, visant a donner 
une forme standard a la presentation des resultats. Par exemple, les normes de 
documentation (plan-type, preimprime) ou les normes de presentation des inter- 
faces homme-machine et des sorties du futur systeme. 

La standardisation des qualifications doit assurer des comportements analogues. 
Elle peut etre obtenue par une politique recrutement de personnels ayant une 
culture commune ou par des formations methodologiques. 

A ces deux sortes de coordination, il faut aj outer : les mecanismes de liaison, 
(figure 5.1) qui permettent d’etablir une coordination laterale. Le comite de pilo- 
tage du projet en est un exemple : il est compose de personnes n’appartenant pas 
a l’equipe de projet qui donnent les grandes orientations ; leur angle de vue est 
celui du projet dans son ensemble, meme si le travail a ete reparti en plusieurs 
sous-projets. 


Personnelle 

Impersonnelle 

Ajustement mutuel 

Standardisation des procedes 

Supervision directe 

Standardisation des resultats 


Standardisation des qualifications 

Mecanismes de liaison 

Comite de pilotage 

Administration de donnees 


Figure 5.1 — Formes de coordination. 
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On distingue parfois le comite de pilotage client et le comite de pilotage 
interne [AFITEP, 2000]. Le premier est defini comme un « groupe de personnes 
responsables, chez le client, jouant le role de maitre d’ouvrage vis-a-vis du chef de 
projet ». Le second vise a apporter une aide au chef de projet, dans certains 
projets difficiles : « compose de responsables de niveau suffisant, il prendra, face au 
client, les grandes options strategiques et les decisions correspondan tes ». 

Un dispositif de liaison joue un role particulierement important dans les 
projets de developpement de systeme d’information : il s’agit de l’ administration 
de donnees. Nous allons en developper les differents aspects. 

5.1.3 L’ administration de donnees (AD) 

Cette fonction a pour mission de construire et gerer un systeme d’information sur 
le systeme d’information de l’entreprise, souvent appele referential. Elle peut assurer 
la coordination a l’interieur d’un projet : c’est alors un dispositif temporaire. Si elle 
est au contraire permanente, elle permet de coordonner differents projets, et fonc- 
tionne egalement en dehors de tout projet. On distingue quatre formes d’AD : 

• l’AD technique ; 

• l’AD projet; 

• l’AD coordination ; 

• l’AD pilotage. 

L’AD technique gere des descriptions proches de la structure des donnees 
informatiques. Ces descriptions font partie de la documentation des applica- 
tions. Si ces informations sont absentes, ou bien n’ont pas integre les evolutions 
de l’application, on peut les produire au moyen d’une operation de retro- 
documentation. Le champ couvert est circonscrit a celui d’une application. Il est 
parfois elargi dans le cas d’une base de donnees partagee par plusieurs applica- 
tions. Les outils utilises sont des dictionnaires de donnees techniques, soit lies a 
un systeme de gestion de base de donnees (par exemple, le dictionnaire DB2 ou 
le dictionnaire Oracle), soit lies a un atelier de genie logiciel generateur de code. 

L’AD projet gere les donnees specifiques d’un projet, telles qu’elles sont defi- 
nies au niveau semantique. La structure n’est interessante que par le sens dont 
elle est porteuse. Ainsi, l’identification des proprietes d’une entite permet de 
preciser sa signification et son role dans le systeme d’information. Cette forme 
d’administration de donnees, que Ton pourrait appeler plus justement adminis- 
tration des informations, decoule du besoin de concevoir les applications a un 
niveau proche du systeme de gestion, en y associant les gestionnaires. Elle 
accompagne la conception et assure la coordination entre tous les intervenants 
du projet. On utilise pour cela les dictionnaires lies aux ateliers de genie logiciel 
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de conception. L’ articulation entre dictionnaire des donnees physiques (celles de 
PAD technique) et dictionnaire des donnees conceptuelles n’est pas toujours 
mise en place. Certaines operations de retroconception ont pour objectif de 
reconstruire a posteriori ce lien. 

L’AD coordination gere des informations conceptuelles consolidees. Les donnees 
y sont definies au meme niveau que dans PAD projet et avec la meme maille de 
description, mais le champ couvert est multiprojet. Ainsi, dans le cas d’une refonte 
d’une partie importante du systeme d’information de Pentreprise, PAD coordina- 
tion mettra en coherence les definitions des donnees issues de chaque sous-projet. 
On peut aussi installer une AD coordination pour eviter des divergences entre les 
differentes etudes detaillees issues d’une meme etude prealable. Ou encore, pour 
federer tous les projets d’un departement. L’apport de PAD coordination est de 
reduire les phenomenes d’autisme (« je ne parle avec personne ») ou de babelisa- 
tion (« on se cause, mais on ne se comprend pas ») de certaines applications. En 
soulevant les barrieres des projets, elle etend le champ de la reutilisation. 

L’AD pilotage foumit des representations synthetiques, supports d’une planifica- 
tion strategique des systemes d’informations. C’est par exemple a ce niveau que l’on 
reflechira sur les liens Contrat-Client (contrat multiclient) ou les liens Contrat- 
Produit (contrat multiproduit). Sa maille de description depend du niveau auquel 
le besoin de pilotage se situe. Ce peut etre un departement, une filiale, toute l’entre- 
prise, en fait tout sous-systeme quasi autonome ayant une capacite de pilotage. 

Chaque forme represente une reponse complete a un type de probleme. Dans 
une perspective dynamique, certaines contraintes d’enchainement doivent etre 
neanmoins respectees (figure 5.2). 


AD technique 1 


AD projet 1 



Figure 5.2 — EnchaTnement des formes d’administration de donnees. 


Les formes 1 et 2 sont independantes. En effet, PAD projet peut etre suivie ou 
non d’une AD technique. Inversement, PAD projet peut etre precedee d’une 
AD technique, par exemple si le projet est la refonte d’une application existante, 
sur laquelle on mene une operation de retrodocumentation. 
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Par contre, FAD pilotage doit etre precedee d’une AD coordination stabilisee. 
De fagon analogue, FAD coordination doit pouvoir s’appuyer sur des AD projet 
solides. Ensuite, elle alimente partiellement Fadministration des nouveaux projets. 

L’AD pilotage peut etre mise en place sur une partie seulement de l’entre- 
prise, pour laquelle on est deja en forme 3. 

La plupart des entreprises sont aujourd’hui en forme 2 ou 3. 

5 . 1.4 Les parties prenantes et les structures-types d’un projet 

Longtemps, on s’est principalement interesse aux acteurs d’un projet, c’est- a-dire 
a ceux qui ont des responsabilites vis-a-vis du travail a effectuer. Aujourd’hui, on 
elargit la perspective a l’ensemble de ceux qui sont concemes ou peuvent etre 
impactes par le projet : c’est ce que l’on appelle les parties prenantes. Nous propo- 
sons au chapitre 9, dans le cadre de la maitrise des risques, un exercice d’ analyse 
des parties prenantes d’un projet (§ 9.2). Nous allons maintenant approfondir la 
notion d’acteur. 

Un acteur est quelqu’un qui joue un role dans le deroulement du projet. La 
notion de role est importante dans un univers projet. C’est une fonction tempo- 
raire, deconnectee de la place qu’occupe la personne dans l’organigramme de 
l’entreprise ; on attache au role des activites a effectuer et une responsabilite. 

Quand on organise un projet, on commence par determiner les roles neces- 
saires. On distingue trois types d’acteurs (figure 5.3) participant a un projet de 
developpement de systeme d’information : 

• le couple maitre d’oeuvre-maitre d’ouvrage ; 

• l’equipe de projet ; 

• les utilisateurs. 


Typologie des acteurs 

Couple maitre d’oeuvre-maitre d’ouvrage 

Equipe de projet 
chef de projet 
concepteur 
developpeur 

Utilisateur 

final 

gestionnaire 

decideur 


Figure 5.3 — Typologie des acteurs d’un projet systeme d’information. 
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Les roles de maitre d’ oeuvre et maitre d’ouvrage sont issus des grands projets 
industriels. Ils sont lies par une relation contractuelle. Dans le domaine des 
systemes d’information, les modalites de cette relation ont fait l’objet d’un projet 
europeen, Euromethode : nous en presentons les resultats au chapitre 16. Le 
maitre d’ouvrage represente le client. Partant d’une demande des futurs utilisa- 
teurs du systeme, il etablit un cahier des charges qui peut servir de base a un 
appel d’offres. Apres discussions sur une ou plusieurs propositions regues, il passe 
contrat avec un fournisseur qui jouera le role de maitre d’oeuvre. Celui-ci est 
responsable de la conduite du projet. Le maitre d’ouvrage assure un suivi de 
l’avancement du projet, selon des modalites contractuellement definies. A 
chaque fourniture contractuelle par le maitre d’oeuvre, il precede a la recette et 
prononce l’acceptation ou le refus. Il pilote la mise en oeuvre du projet. 

Rigoureusement parlant, l’ouvrage est le resultat concret d’un projet : cons- 
truction, materiel, progiciel. L’AFITEP et l’AFNOR [AFITEP, 2000] definissent 
le maitre d’ouvrage comme « la personne physique ou, le plus souvent, personne 
morale qui sera le proprietaire de I’ouvrage. Ilfixe les objectifs, Venveloppe budgetaire 
et les delais souhaites pour le projet ». Ace titre, il « assure le paiement des depenses 
liees a la realisation » . 

L’oeuvre est definie comme « le processus de realisation de 1’ outrage, c’est-a-dire 
la mise en place des moyens necessaires & cette realisation et a leur conduite » . Par 
consequent, elle « est constitute de X ensemble, des tdches, regroupees ou non en lots 
de travaux ». 

Le maitre d’oeuvre est « la personne physique ou morale qui realise I’ouvrage pour 
le compte du maitre d’ouvrage et qui assure la responsabilite globale de la qualite tech- 
nique, du delai et du coiit ». 

La transposition de ces deux roles quand il s’agit de systeme d’information 
renvoie davantage a la repartition des responsabilites qu’a la notion de propriete. 
En effet, meme si l’on parle parfois du « proprietaire d’une application informati - 
que », il est difficile d’etendre ce droit de propriete aux processus et aux acteurs. 

L’equipe de projet rassemble differents acteurs, qui sont affectes au projet. 
D’ apres l’AFITEP et l’AFNOR, c’est « X ensemble des personnes placees sous X auto- 
rite directe (et quelquefois indirecte) du chef de projet ». Mais, on peut parfois consi- 
derer que l’equipe de projet s’etend a « toutes les personnes participant a la 
realisation du projet ». 

Le chef de projet est responsable devant le maitre d’oeuvre de l’avancement du 
projet. Nous decrivons plus precisement son role et ses outils au paragraphe 5.3 
et au chapitre 7 qui traite du pilotage du projet. Si l’on a decoupe le projet en 
plusieurs sous-projets, un chef de projet est responsable de l’ensemble du projet 
et chacun des sous-projets a son propre responsable. 


5. La dimension humaine d'un projet 


Le role de concepteur peut etre tenu par un informaticien, un organisateur ou 
un gestionnaire selon le stade d’avancement : sa responsabilite est de concevoir 
le futur systeme aux etapes etude prealable et etude detaillee. 

Le role de developpeur est tenu par un informaticien : sa responsabilite est 
d’ecrire les programmes ou de realiser un prototype. Pour certains developpements 
realises en langage de 4 e generation, le role peut etre tenu par un gestionnaire. 

Concepteurs et developpeurs sont les producteurs de l’equipe. Ils sont assistes 
par d’autres acteurs occupant des roles fonctionnels. 

La figure 5.4 donne un exemple de structure de projet. 



Figure 5.4 — Exemple de structure de projet. 


On a dedouble le role du chef de projet. Le directeur de projet est responsable des 
relations contractuelles avec le client. Le manager est responsable de l’avancement 
du travail. Le premier s’occupe des affaires exterieures, le second des affaires internes. 

Par ailleurs, on voit figurer quatre roles fonctionnels. La fonction administra- 
tion de donnees correspond a PAD projet presente ci-dessus. Le support techni- 
que apporte ponctuellement conseil et assistance aux equipes de production sur 
une technologie ou une methode employee. Le gestionnaire de l’environnement 
est responsable de 1’ atelier de genie logiciel utilise ; parfois, c’est lui prepare les 
environnements de test et de recette. La fonction controle qualite s’assure de la 
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qualite de la production. Ce point sera detaille au chapitre 8 qui traite de la 
qualite. 

Le role de Vutilisateur peut etre mis en correspondance avec des fonctions 
permanentes. On va reperer des acteurs qui vont jouer pour le projet les roles des 
utilisateurs, qu’ils soient ou non les veritables utilisateurs du futur systeme. Ils 
auront la responsabilite de s’exprimer en tant qu’utilisateurs. On peut distinguer 
trois categories. 

Vutilisateur final est celui qui va utiliser les transactions et les editions du futur 
systeme dans son travail au quotidien. C’est, par exemple, Temploye de l’agence 
bancaire qui se sert de son terminal pour effectuer les operations avec la clientele. 
La responsabilite attachee a ce role est d’exprimer des besoins et des contraintes 
liees au travail courant. 

Vutilisateur gestionnaire est un operationnel qui a des responsabilites d’enca- 
drement. II utilisera le futur systeme pour obtenir des informations permettant 
de prendre des decisions de gestion. Par exemple, un responsable produit attendra 
des informations permettant de suivre une vente promotionnelle. La responsabilite 
attachee a ce role est d’exprimer des besoins en informations favorisant la gestion 
a moyen terme de l’activite. 

Vutilisateur decideur a le pouvoir de modifier les regies du systeme de gestion, 
pour utiliser au mieux les possibilites technologiques. Sa responsabilite est de 
prendre des decisions sur revolution des regies de gestion. 

5.1.5 La composition de i’ equipe de projet 

On a evoque au paragraphe 5.1.1 les criteres de repartition du travail a Tinterieur 
d’une equipe de projet. Nous allons approfondir ce point sous l’angle des profils 
psychologies, a partir de la methode des roles de M. Belbin 1 . Ce dernier a 
mene pendant plus de 20 ans a Cambridge des etudes sur le fonctionnement des 
groupes de travail et a conclu qu’il n’existe qu’un nombre limite de positionne- 
ments dans l’equipe. La performance d’une equipe depend de Tequilibre de ces 
positionnements, appeles « roles », parmi les membres. Au-dela de la repartition 
des activites, chacun endosse en general un « role », et des « roles » complemen- 
taires favoriseront la synergie, alors que des « roles » non endosses manqueront 
dans la dynamique du groupe. 

M. Belbin a identifie neuf types de « roles » regroupes en trois categories, 
selon Torientation majeure : vers les personnes, vers Taction ou vers la production 
intellectuelle. 


1. Meredith Belbin, Les roles en equipe, Ed. Organisation, 2006. 
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Les « roles » orientes vers les personnes sont les suivants : 

1. Le « coordinateur a tendance a clarifier les buts et favoriser la prise de 
decision dans le groupe. 

2. Le « coequipier » est attentif aux autres et les encourage. 

3. Le « pourvoyeur de ressources » dispose d’un carnet d’adresses qu’il est pret 
a ouvrir pour les membres du groupe. 

Les « roles » orientes vers faction sont les suivants : 

1. L’« organisateur » a tendance a traduire les idees en taches concretes. 

2. L’« entraineur » aide l’equipe a conserver le cap vers les objectifs et main- 
tient la pression. 

3. Le « controleur » verifie les details, il a le souci du respect du calendrier et 
des engagements. 

Les « roles » orientes vers l’intellect sont les suivants : 

1. L’« innovateur » propose de nouvelles idees, mais il peut etre irrealiste et 
peu communicateur. 

2. L’« evaluateur » est au contraire realiste et il aime analyser les problemes 
complexes. 

3. Le « specialiste » possede des connaissances precises, utiles a l’equipe. 

La methode Belbin s’appuie sur une serie de questionnaires traites par un 
systeme expert, INTERPLACE. Avoir recours a la methode Belbin peut etre 
interessant lorsque l’on constate que, sans raison apparente, une equipe ne four- 
nit pas les resultats escomptes. Si Ton a identifie les roles endosses par chacun, 
on peut augmenter l’efficacite de l’equipe en jouant, a bon escient, sur sa compo- 
sition ou sur son fonctionnement interne. 


5.2 LA PARTICIPATION DES UTILISATEURS 

Quand on evoque l’intervention d’utilisateurs dans un projet, on emploie 
souvent le terme generique de participation. En realite, la nature et les modalites 
de participation peuvent presenter une grande variete. On ne peut pas parler de 
participation dans l’absolu ; elle peut prendre differentes formes et servir diffe- 
rents buts. Dans une perspective de pilotage de projet, on considere que la parti- 
cipation peut avoir un effet sur la determination des besoins, sur le processus de 
decision ou sur une evolution organisationnelle. 
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5.2.1 La determination des besoins 

La participation peut avoir pour objectif de transferer a l’equipe de projet une 
connaissance sur un domaine, un systeme de gestion, une organisation existante. 
Ceci est en general facile a obtenir. Cependant, les utilisateurs sollicites sont 
ensuite dans un etat d’attente : ils savent qu’un projet a demarre, ils expriment 
davantage qu’un existant, mais egalement des remarques, critiques, propositions, 
souhaits... 

Si on veut limiter ces effets, il est preferable de reduire le nombre d’informa- 
teurs, voire de chercher un informateur exteme. Si au contraire on veut destabi- 
User, c’est-a-dire provoquer un besoin, il faut elargir la consultation, avec 
cependant la necessite de gerer ensuite cette destabilisation. 

5.2.2 La prise de decision 

La participation peut faciliter le processus de decision de plusieurs fagons. Tout 
d’abord, supposons que le systeme de gestion doive etre pense ou repense. Il 
s’agit de faire des choix importants de conception, c’est-a-dire qui auront un 
impact sur le futur systeme d’information. La participation des utilisateurs est 
necessaire, parce que ce sont souvent des choix strategiques qui ne relevent pas 
du domaine des informaticiens. 

Ensuite, tout projet est jalonne de prises de decision lors d’activites plus ou 
moins formalisees de validation. Mais les decisions sont parfois difficiles a obte- 
nir. La participation peut faciliter l’obtention de decisions sur des options de 
conception et d’organisation. Il s’agit de faire en sorte que les choix soient faits 
par ceux qui mettront en oeuvre le futur systeme d’information. Souvent, un ou 
deux utilisateurs sont integres au groupe de conception et un groupe plus large 
est sollicite pour avis et validation. Si les utilisateurs sont multiples, la prise de 
decisions passe par la construction d’un consensus. 

Enfin, la participation peut rechercher des decisions d’orientation et de 
poursuite du projet. Les utilisateurs vises sont des decideurs, ils ne s’implique- 
ront pas dans les choix fins de conception, mais la poursuite du projet pourra 
dependre de leur appreciation et de leur engagement. Cette participation se 
fait generalement a travers un comite de pilotage, mais elle peut etre plus 
informelle. Prendre une decision, c’est souvent prendre un risque. Celui-ci est 
d’autant plus grand que les consequences du choix se font sentir a moyen ou 
long terme. C’est pourquoi on observe parfois une reticence a s’engager. La 
participation permet de reduire cette crainte, en donnant aux decideurs une 
meilleure connaissance du projet et en offrant des possibility d’echange et de 
discussion avec d’autres acteurs. 
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5.23 Le changement 

La participation peut faciliter [’utilisation du futur systeme par l’utilisateur final. 
C’est un moyen pour que les changements soient acceptes positivement par ceux qui 
auront a les vivre. Cette participation n’a generalement pas d’impact sur la conception. 

De plus, si le futur systeme peut etre contourne, il faut obtenir Pengagement 
de Putilisateur, pour qu’ensuite il Palimente et en utilise les sorties possibles. 
Cet engagement sera obtenu s’il a participe au projet. Comme la totalite des 
utilisateurs finaux ne peut en general pas etre associee pour des raisons prati- 
ques, cout de la participation et difficult^ de faire converger des demandes 
nombreuses, on s’appuie souvent sur un groupe phare, dont le comportement 
aura un effet exemplaire. 

La participation peut enfin provoquer un changement de comportement des 
utilisateurs. L’ association aux taches de production et aux decisions peut modifier 
les comportements, soit entre groupes d’ utilisateurs (par un dialogue autour du 
futur systeme), soit en rendant possible une autre organisation. 


53 LE ROLE DU CHEF DE PROJET 

53.1 Definition du chef de projet 

Le chef de projet est defini par l’AFITEP et l’AFNOR comme : « la personae 
physique chargee par le maitre d’ oeuvre, dans le cadre d’une mission definie, d’ assurer 
la maitrise du projet, cest'd'dire de veiller a sa bonne realisation dans les objectifs de 
technique, de cout et de delai. » 

Cette definition est insuffisante pour les projets systeme d’information. 
Heureusement, la definition est elargie : « Souvent le maitre d’ouvrage identifie , en 
son sein, un interlocuteur au chef de projet du maitre d’ oeuvre. Cet interlocuteur est 
aussi appele chef de projet » [AFITEP, 2000]. 

Compte tenu de la definition d’un systeme d’information donnee au paragra- 
phe 1.4, le chef de projet devrait toujours etre du cote maitre d’ouvrage, avec un 
chef de projet informatique comme interlocuteur. 

53.2 Les responsabilites du chef de projet 

Le chef de projet doit faire en sorte que le projet reussisse. Pour cela, sa respon- 
sabilite est multiple (figure 5.5) : il a la charge d’une bonne gestion du groupe et 
des individus ; il pilote la production des livrables pour un achevement en temps 
et en heure ; il participe a la gestion du changement, en particulier aupres des 
acteurs cles du projet ; il lui revient enfin de veiller a ce que les processus de 
decision ne soient pas bloques. 
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Figure 5.5 — Responsabilites du chef de projet. 


II est responsable du groupe. D’un ensemble d’individus, il doit constituer une 
equipe, l’animer et en maintenir la cohesion. L’equipe prend corps lorsque 
l’objectif (le projet) devient collectif. Pour obtenir cette adhesion et cette syner- 
gic, il faut que chacun soit — et se sente — responsable en propre d’une partie 
du travail ; il faut favoriser les echanges lateraux grace notamment a des points 
reguliers de coordination. L’esprit de groupe se construit par des echanges directs 
d’individu a individu sur un but commun. C’est pourquoi il est souhaitable que 
la taille de l’equipe reste limitee. Au-dela de quinze a vingt personnes, le senti- 
ment d’appartenance se dilue. 

Le chef de projet est responsable des individus membres de l’equipe, qu’il doit 
valoriser et soutenir. Ce domaine est l’un de ceux ou, par chance, le travail est 
souvent un moyen de se realiser. Or, la satisfaction qu’un acteur retire de son acti- 
vity sur le projet est le plus puissant des moteurs. Chercher a ce que chacun se 
sente gratifie par le travail accompli est une excellente approche manageriale. 

Le chef de projet doit prendre en compte les souhaits des individus et l’enri- 
chissement apporte, lorsqu’il attribue les taches. L’estimation de la charge affec- 
tee doit etre negociee avec celui qui va accomplir la tache correspondante. S’il y 
avait disaccord des le depart, le risque serait grand de depasser le delai. 

L’avancement doit etre suivi de pres, pour ne pas laisser l’un ou l’autre pietiner. 
En cas de difficulty, le dialogue est indispensable. Un retard sur une tache peut etre du 
a une cause exogene (panne de la machine de developpement) ou organisationnelle 
(demande de fonctionnalite supplemental ), qui est du ressort du chef de projet. 

Le chef de projet est egalement responsable de V avancement des travaux et doit 
convaincre l’equipe de la necessity d’un suivi adequat. Le systeme d’information 
projet est indispensable a la reussite : il faut que les chiffres de base soient le plus 
juste possible. Pour cela, le chef de projet doit utiliser avec perspicacite les 
chiffres issus du bilan individuel. Les informations du compte rendu d’avance- 
ment doivent etre traitees immediatement. 
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Le chef de projet est un acteur du changement parmi les utilisateurs. II doit pour 
cela organiser une participation adaptee afin de creer un noyau qui portera le 
changement. Si aucune dynamique n’a ete declenchee parmi les utilisateurs, la 
mise en oeuvre risque d’etre difficile et le succes du projet compromis. II appar- 
tient au chef de projet de reperer et d’associer au projet certains utilisateurs 
convaincus de son utilite et qui s’en feront les herauts. 

Le chef de projet est, a certains egards, le pilote des decisions touchant au 
contenu du projet. Toute decision a prendre, si elle n’est pas prise immediate- 
ment, doit lui etre signalee. Toutes celles qui sont en suspens doivent figurer sur 
son tableau de bord, pour qu’il en suive le traitement. II doit parfois aider a choisir 
en apportant un eclairage aux decideurs ou en proposant des solutions flexibles si 
un choix definitif ne peut etre fait. 

Nous allons developper trois aspects qui concement un chef de projet : 
d’abord, les styles de management d’equipe et leur adequation ou inadequation a 
differentes situations pour atteindre les objectifs enonces ci-dessus ; ensuite, la 
motivation des membres de l’equipe ; enfin la gestion des conflits a l’exterieur du 
groupe de projet. 

533 Les styles de management 

Dans les travaux intellectuels, les ecarts de productivite peuvent etre tres impor- 
tants, aussi bien dans les etudes que dans le developpement. Les methodes 
d’analyse et les methodes de programmation visent a reduire ces ecarts qui 
peuvent aller couramment de 1 a 5. Cependant, le chef de projet peut avoir une 
influence decisive sur la productivite : 

• d’abord en estimant les charges, c’est-a-dire en donnant une base de 
reference ; 

• ensuite en assurant un suivi regulier de l’avancement ; 

• enfin, en manageant l’equipe avec discemement. 

II n’existe pas un style de management universellement efficace. Le style le 
plus adequat depend a la fois de la personnalite du chef de projet et de la situation 
au moment ou l’on agit (figure 5.6). Un style de management est adequat s’il 
permet d’augmenter a la fois la productivite et la satisfaction de l’equipe de projet. 

On distingue souvent cinq styles de management, selon le degre et la forme 
de participation des membres de l’equipe aux decisions de gestion du projet : 

• le style directif ; 

• le style consultatif ; 

• le style participatif ; 

• le style persuasif ; 

• le style par delegation. 
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Le style directif donne au chef de projet une place preponderate dans la prise 
de decision : il decide seul de l’organisation du travail, des regies de fonctionne- 
ment et des solutions a apporter aux differents problemes et aleas. On distingue 
parfois deux formes. 

Si le chef de projet etudie les problemes et prend seul les decisions, on parle 
du style directif seul. 

Si le chef de projet recueille des elements d’information aupres de l’equipe, 
puis decide seul, il s’agit du style directif apres information. 

Le style consultatif consiste a susciter l’avis des membres de l’equipe. Le chef de 
projet prend ensuite une decision qui n’est pas forcement le reflet des opinions 
du groupe. Comme le precedent, il peut prendre deux formes. 

Si le chef de projet recueille les opinions en discutant individuellement avec 
chacun, on l’appelle style consultatif individuel. 

Si le chef de projet recueille les avis de l’equipe lors d’une discussion de 
groupe, c’est le style consultatif groupe. 

Le style participatif conduit le chef de projet a associer les membres de l’equipe 
aux decisions, notamment sur l’organisation du travail et la gestion des aleas. Cela 
demande au chef de projet des capacites d’ecoute, de collaboration et de recherche 
de consensus. Ce style peut comme les precedents prendre deux formes. 

Si le chef de projet associe individuellement chacun des membres et recher- 
che une decision satisfaisante pour le plus grand nombre de personnes, on le 
nomme style participatif individuel. 

Si le chef de projet reunit son equipe pour une recherche et une evaluation 
collective des differentes solutions, on parle de style participatif groupe. 

Le style persuasif vise a augmenter 1’ adhesion des membres de l’equipe au 
projet. Le chef de projet passe un temps important a parler a l’equipe des objec- 
tifs du projet, de son importance, du role de chacun et de la pertinence de l’orga- 
nisation et des decisions prises au cours du projet. Il suscite des reactions et 
cherche a convaincre. 
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Le style par delegation laisse une grande part a la responsabilite personnelle 
notamment dans la conduite des travaux a mener : le chef de projet foumit les 
informations a un membre de l’equipe et lui laisse complete initiative de traiter 
le probleme. Ce style necessite une confiance partagee, ce qui ne signifie pas 
aveuglement car il s’accompagne d’un systeme de suivi precis. II favorise 
l’apprentissage et l’autonomie des membres de l’equipe. 

Pour choisir un style adequat lorsque Ton doit prendre une decision ou traiter 
un probleme, il faut se poser les questions suivantes : 

• La nature de la decision ou solution retenue peut-elle avoir un impact 
important sur les trois sommets du triangle projet : cout, delais, qualite ? 

• Le chef de projet dispose-t-il des informations necessaires pour decider ? 

• Si le chef de projet decide seul, sa decision sera-t-elle acceptee par l’equipe ? 

• L’ acceptation de la decision par les membres de l’equipe peut-elle avoir un 
effet sur l’efficacite de sa mise en oeuvre ? 

• Peut-il y avoir des conflits entre les membres de l’equipe sur la decision a 
prendre ? 

• Les membres de l’equipe peuvent-ils avoir des avis pertinents sur la deci- 
sion a prendre ? 

• Les contraintes de delais sont-elles fortes ? 

Selon les reponses apportees a ces differentes questions, on est conduit a privi- 
legier ou a ecarter un style de management pour traiter le probleme ou prendre la 
decision. Le tableau de la figure 5.7 resume les situations pour lesquelles il faut 
privilegier et/ou e viter chacun des styles de management. Le choix n’est pas 
forcement unique pour une situation donnee. 

5.3.4 Les theories de la motivation 

La motivation, comme disposition incitant l’individu a foumir sans contrainte 
une prestation satisfaisante en qualite et quantite, a fait l’objet de nombreuses 
theories depuis plus d’un demi-siecle. Nous allons les parcourir rapidement pour 
montrer les differents angles sous lesquels on peut l’aborder. 

Une des theories les plus anciennes est celle de la hierarchie des besoins 
d’A. Maslow 1 . Les etres humains sont soumis a des besoins ordonnes : tant qu’une 
strate n’est pas satisfaite, l’individu ne peut pas se preoccuper des niveaux superieurs. 


1. Abraham Maslow, Devenir le meilleur de soi-meme : Besoins fondamentaux, motivation et person - 
nalite, Ed. Organisation, 2008. L’ouvrage initial, Motivation and personality, fut publie en 1954. 
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Style de management 

A utiliser si 

A eviter si 

Directif seul 

Les contraintes de delai 
sont tres fortes. 

L’equipe est composee 
de debutants. 

Le chef de projet manque 
d’information. 

Directif apres information 

On est en situation 
de crise. 


Consultatif individuel 

Le chef de projet manque 
d’information. 


Consultatif groupe 


H y a risque de conflit 
entre les membres de 
l’equipe. 

Participatif individuel 

Le collaborateur est 
experiments . 

Le collaborateur adhere 
aux objectifs du projet, 
mais il peut y avoir un 
conflit avec lui sur la 
decision. 

L’implication du collabo- 
rateur a peu d’influence 
sur la mise en ceuvre de 
la decision. 

Participatif groupe 

Les membres de l’equipe 
sont experimentes. 

Les membres de l’equipe 
adherent aux objectifs 
du projet et ils pourraient 
etre en disaccord entre 
eux sur la solution. 

L’equipe manque d’infor- 
mation ou d’ experience. 

Les membres de l’equipe 
n’ adherent pas pleine- 
ment aux objectifs du 
projet. 

Persuasif 

L’equipe est composite, 
avec des membres venant 
de departements ou 
d’entreprises differentes. 


Par delegation 


Le collaborateur 
n’ adhere pas pleinement 
aux objectifs. 

Le collaborateur est 
inexperimente. 


Figure 5.7 — Le choix d’un style de management. 
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II propose la classification croissante : 

1. Les besoins physiologiques (faim, soif, sante..) doivent etre assures en premier. 

2. Puis, l’individu recherche la securite (protection contre dangers, mena- 
ces...). 

3. Ensuite apparaissent les besoins sociaux (, appartenance a un groupe, 
acceptation sociale, echanges...). 

4. L’individu peut alors rechercher des activites et des situations qui lui 
permettent d’etre reconnu et developpent l’estime de soi. 

5. Enfin, l’etre humain cherche a se realiser par l’exploration, la decouverte, 
les connaissances... 

Cette classification, bien qu’un peu sommaire, attire 1’ attention sur les multiples 
sources de motivation et sur la necessite de faire une analyse de ce qui apparait 
comme primordial a un moment donne. 

La theorie des facteurs d’hygiene de F. Herzberg 1 , un des theoriciens de l’enri- 
chissement du travail en milieu industriel, a affine l’approche hierarchique. II a 
propose de distinguer entre « facteurs d’hygiene » et facteurs de motivation. 
L’analogie s’appuie sur le fait qu’un manque d’hygiene ouvre la porte a la maladie, 
mais une bonne hygiene n’est pas suffisante pour garantir la sante. 

Les facteurs d’hygiene sont sources potentielles d’insatisfaction et sont lies au 
contexte du travail : regies administratives, salaire, conditions materielles, relations 
avec l’encadrement. . . Les facteurs de motivation sont des sources potentielles de 
satisfaction, done de motivation. Ils touchent au contenu du travail : responsabilite, 
reussite, promotion... 

La theorie XJY de D. McGregor 2 s’interesse aux managers et au regard que 
ceux-ci portent sur l’etre humain au travail. Les actes de management des 
personnes reposent sur des hypotheses, en general implicites, chez les managers. 
II distingue ainsi deux styles de management. 

Selon la « theorie X », l’etre humain ressent une aversion pour le travail, a 
generalement peu d’ambition et evite responsabilites. Pour obtenir un travail 
satisfaisant, ilfaudra done contraindre, menacer, controler... 

Selon la « theorie Y », le travail peut, au contraire, etre une source de satis- 
factions. L’etre humain est capable aussi bien d’autonomie que d’apport creatif, il 
est done recommande d’utiliser ce potentiel d’engagement, notamment en asso- 
ciant le collaborateur aux objectifs poursuivis. 


1. Frederick Herzberg, Le travail et la nature de I’homme, Entreprise modeme d’edition, 1978. 
L’ouvrage initial, The motivation to work, fut publie en 1959. 

2. Douglas McDonald, La dimension humaine de l’ entreprise, Bibliotheque du Management, 1970. 
L’ouvrage initial, The human side of enterprise, fut publie en 1960. 
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Sans reduire l’ensemble des managers a deux categories, il peut etre interes- 
sant que le chef de projet s’interroge sur ses propres orientations de management 
individuel de l’equipe. 

La theorie Z de W. Ouchi 1 2 est un clin d’oeil a celle de McGregor. II propose 
d’utiliser les principes d’organisation des entreprises japonaises, qui conduisent 
a une performance individuelle superieure a celle des entreprises americaines. 
Les valeurs pronees sont orientees vers le groupe : inclusion totale de l’individu 
dans l’entreprise, primaute absolue au groupe, prise decision participative... Le 
principe defendu est que la motivation des individus depend de leur integration 
dans le corps collectif. Cette position etait notamment liee a la pratique de 
l’emploi a vie dans les grandes entreprises japonaises, en partie remis en question 
aujourd’hui. 

Plusieurs theories ont etudie le caractere relatif et subjectif de la satisfaction 
dans le groupe. Selon les theories de Vequite 1 , le comportement (en quantite et 
en qualite) depend des sanctions et recompenses attendues en regard du travail 
fourni, ainsi que de parametres comme l’age, l’experience, le niveau d’educa- 
tion. . . Le point central est que l’individu elabore des comparaisons avec d’autres 
ou avec situations anterieures. 

La perception d’une injustice, c’est-a-dire d’un desequilibre entre sa contribution 
et le resultat obtenu (salaire, responsabilites, rapports sociaux dans le travail, 
avantages indirects...) est une source importante d’ insatisfaction et de reactions 
negatives. 

Dans la meme veine, la theorie des attentes ou theorie de V expectation de 
V.H. Vroom 3 a developpe l’idee que tout individu elabore des attentes sur les 
resultats de son travail. II propose des principes, dont l’application devrait 
conduire a ce que les motivations individuelles coincident avec celles de l’orga- 
nisation. En particulier, les regies de distribution des recompenses devraient etre 
clairement comprises ; les recompenses sont en proportion des efforts necessai- 
res ; l’individu peut controler la partie de sa performance qui est liee aux recom- 
penses ; et 1’ individu ne pergoit pas de conflit entre une recompense a court 
terme (liee par exemple a une bonne productivity) et une sanction a long terme 
(elevation des standards). 

En conclusion, la motivation est un phenomene complexe, et les facteurs qui y 
contribuent peuvent etre d’ordre personnel, interpersonnel ou organisationnel. 

1. Theory Z : How American Business Can Meet the Japanese Challenge, 1981. Theorie Z, faire face 
au defi japonais, InterEditions, 1997. 

2. G. Homans, Social behavior, its elementary forms, 1961 ; F. Heider, The psychology of interpersonal 
relations, 1958 ; J.S. Adams, Inequity in social exchange, 1965. 

3. Industrial social psychology, 1969. 
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5.3.5 La gestion des conflits 

L’ analyse des risques, presentee au chapitre 6, permet d’anticiper des conflits 
possibles et de prendre des mesures preventives. Cependant, les imprevus du 
projet peuvent prendre parfois une forme conflictuelle. On fait ici reference a 
des conflits qui se produisent entre pairs, avec un autre chef de projet, ou avec 
un maitre d’ouvrage, ou encore avec un responsable transversal a la Direction 
informatique. 

On distingue en general cinq modes de resolution des conflits 1 : 

• le retrait ; 

• l’apaisement ; 

• la force; 

• le compromis ; 

• la collaboration. 

S’il adopte la strategic du retrait, le chef de projet se retire du conflit, il se 
tient a distance en attendant que les choses se calment. Face a son equipe, il 
peut aller jusqu’a nier l’existence du conflit. 

C’est une strategic a court terme, pertinente pour des conflits de faible intern 
site et dont l’objet n’a que peu d’ impact sur les activites et la reussite du projet. 
On peut egalement l’adopter comme une attitude d’attente, lorsque le contexte 
n’est pas propice a un traitement de fond du conflit. 

Si le chef de projet opte pour Yapaisement, il va rencontrer la personne avec 
laquelle il est en conflit et tenter de minimiser les oppositions, en soulignant les 
elements de rapprochement. 

Cette strategic suppose que l’autre personne — ou les autres personnes — ne 
souhaite pas non plus aborder le conflit de front. Le chef de projet mise sur les 
effets du temps, qui relativise les oppositions. Il est soucieux de ne pas deteriorer 
la communication. Ce peut etre une strategic temporaire, en attendant de traiter 
l’objet du conflit en profondeur. Cela est particulierement vrai si l’apaisement 
conduit a une harmonie superficielle, done peu durable. 

Si le chef de projet decide de recourir a une strategic de force, cela signifie qu’il 
va utiliser une position de pouvoir, la sienne ou celle d’un tiers qui lui est favora- 
ble, pour imposer son point de vue et faire adopter la decision qu’il preconise. 

Cette strategic peut avoir des consequences a long terme sur la communica- 
tion avec les partenaires avec lesquels on est en conflit. Ce mode de resolution 


1. La presentation est adaptee de [Kezsbom et al., 1989]. 
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peut faire l’objet d’un accord entre les parties : s’en remettre a la decision d’une 
autorite, par exemple l’arbitrage d’un Comite de pilotage. 

S’il suit la strategic du compromis, le chef de projet va entrer en negociation avec 
la personne avec laquelle il est en conflit. Chacun va ceder partiellement pour 
aboutir a une solution acceptable. II peut parfois faire intervenir un mediateur, 
c’est-a-dire une personne non engagee dans le conflit, pour mener la negociation. 

Cette strategie ne conduit pas toujours a la meilleure solution, quand il s’agit 
d’un conflit portant sur des options techniques ou des exigences de qualite. 

S’il choisit la strategie de collaboration, le chef de projet doit reconnaitre la 
valeur des positions adverses. Le conflit peut etre source d’enrichissement et 
d’amelioration de la qualite pour le projet. 

Ce mode de resolution suppose, en general, qu’il ne s’agit pas d’un face-a-face 
entre deux adversaires, mais que differentes positions se sont exprimees. Un 
groupe de travail peut, par un travail d’echange et de prise en compte de points 
de vue adverses, conduire a une solution satisfaisante pour toutes les parties. 
Cela suppose un engagement important dans le projet et une volonte partagee 
d’atteindre au mieux l’objectif. Si le temps est compte, ce mode de resolution 
peut etre dangereux. 

Les styles de management et la gestion des conflits seront illustres dans la 
deuxieme partie au chapitre 13. 


54 LA GESTION DU CHANGEMENT 

5.4.1 La nature et le contenu de la gestion du changement 

Les technologies de l’information peuvent etre un facteur cle d’amelioration du 
fonctionnement de l’entreprise et de sa creation de valeur : reduction des cycles 
de traitement, augmentation de la qualite, nouveau service, efficacite accrue... 
Cependant, ce ne sont pas les technologies en elles-memes qui sont garantes 
d’amelioration, mais les systemes d’information qui en font une utilisation parti- 
culiere. Or, la definition d’un systeme d’information integre les acteurs participant 
au systeme : 

Le systeme d’information est la partie du reel constitute d’informations 
organisees, d’evenements ayant un effet sur ces informations et d’acteurs qui 
agissent sur ces informations ou a partir de ces informations, selon des processus 
visant une finalite de gestion et utilisant les technologies de l’information. Il 
s’appuie sur un systeme informatique, ensemble organise d’objets techniques — 
materiels, logiciels, applications — dont la mise en oeuvre realise son infrastructure. 
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Par consequent, la reussite d’un systeme d’information rend necessaire son 
appropriation par les acteurs concemes. Cependant, les changements apportes 
par le nouveau systeme, en particulier dans ses aspects informatiques et organi- 
sationnels, peuvent parfois conduire a un rejet, rendant le nouveau dispositif 
inefficace. II est done important de comprendre les phenomenes en jeu, pour 
pouvoir adopter une attitude appropriee. 

On peut distinguer deux attitudes selon le degre d’engagement apporte par les 
dirigeants de l’entreprise et les responsables du projet 1 : 

• Le soutien consiste a encourager l’adoption du nouveau systeme ou de la 
nouvelle technologie par une attitude positive et bienveillante. II y a peu 
d’actions planifiees de fagon centralisee et le changement va s’operer a 
partir des evolutions et initiatives individuelles ou locales. Ce fut le cas 
dans les annees 1980 pour l’introduction de la micro- informatique dans 
beaucoup de grandes entreprises, ou bien dix ans plus tard pour l’utilisation 
du courrier electronique. 

• L ’implication consiste a prendre des mesures pour assurer l’assimilation du 
nouveau systeme et un fonctionnement efficace et efficient. Lorsqu’il 
s’agit de mettre en oeuvre un systeme d’information tel que nous l’avons 
defini ci-dessus, le soutien ne permet generalement pas d’atteindre les 
avantages attendus du nouveau systeme ; il est meme parfois imperatif que 
le jeu soit collectif, sous peine de dysfonctionnement graves dans l’activite 
ou le pilotage de l’entreprise. On parle generalement de « gestion du chan- 
gement » pour faire reference aux activites mise en oeuvre quand il y a 
implication, ce qui n’exclut pas une approche participative et partielle- 
ment decentralisee. 

L’objectif de la gestion du changement est de faciliter le passage d’un systeme 
socio-technique existant a un systeme vise. Pour cela, on peut identifier plusieurs 
axes d’apprehension : 

• Le changement est un processus d’apprentissage individuel et collectif. 

• Le changement implique une evolution dans la representation que se font 
les acteurs du systeme, ainsi que de la place et du role qu’ils occupent. 

• Le changement comporte une dimension politique, tous les acteurs ne 
percevant pas ou n’ayant pas le meme interet dans revolution du systeme. 


1. R. Agarwal, M. Tanniru et D. Wilemon, IEEE transactions on EM, 44, 4, 


1997. 
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Du point de vue des acteurs, cela revient a savoir comment faire (utilisation 
du systeme), comprendre pourquoi (apprehension de la logique globale du 
systeme) et participer (convergence entre les strategies des acteurs et les objectifs 
du systeme). 

La gestion du changement implique la planification et la realisation d’un 
ensemble d’activites, On identifie classiquement : la communication, la forma- 
tion, la documentation, l’organisation des sites, la migration, l’experimentation. 
Avant de les decrire, nous allons developper la notion de « resistance au change- 
ment » et le role de la confiance, ainsi que les strategies de deployment dans 
lesquelles ces activites s’inscrivent. 


5.4.2 La resistance au changement 

Le concept de resistance au changement a parfois ete presente comme un facteur 
explicatif de l’echec de certains systemes d’information : les personnes preferent 
la stabilite et refusent a priori toute evolution. C’est peut-etre oublier que la 
destinee humaine est faite de changement tout au long de son existence, et que 
le cadre dans lequel elle s’inscrit est lui aussi en constante evolution. II est prefe- 
rable de considerer la resistance comme un symptome, pouvant se manifester des 
le debut du projet j usque dans le fonctionnement operationnel du nouveau 
systeme, et de s’interroger sur ses origines, qui relevent souvent plusieurs facteurs. 

De fagon schematique, on distingue souvent trois categories de causes, non 
exclusives : 

• La resistance est due au systeme lui-meme : il s’agit d’une problematique de 
« besoins ». 

Le systeme, en particulier le systeme informatique, apparait insatisfaisant 
en termes techniques (temps de reponses, bugs...), fonctionnels (fonc- 
tions inadequates, informations manquantes, erreurs, taches lourdes...), 
ergonomiques (interfaces inadaptees au contexte metier, apprentissage 
difficile...). 

Pour eviter ce type de resistance, des actions sont mises en oeuvre tout au 
long du projet pour s’assurer de P adequation du futur systeme : partici- 
pation des utilisateurs a Panalyse et a la conception, experimentation sur 
des sites pilotes, planification de la migration de l’ancien vers le nouveau 
systeme. 

• La resistance est bee aux acteurs eux-memes : il s’agit d’une problematique 
d’ attitude individuelle. Deux interpretations ont ete donnees. 

La premiere considere qu’il existe des differences intrinseques entre les 
individus face au changement. Ces differences sont bees au profil psycho- 
logique (innovateur ou conservateur). Il s’agit alors de rassurer et preparer 
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ces utilisateurs, par des actions de communication, de formation et 
d’accompagnement. 

La seconde estime que les differences d’ attitude sont contingentes a une 
situation donnee, c’est-a-dire que la resistance ou l’engagement dependent 
de la perception par l’individu du changement propose. Cette interpreta- 
tion s’inscrit dans le courant theorique appele Modele d’acceptation tech- 
nologique 1 . Dans sa proposition initiale, cette theorie considere que 
l’acceptation et 1’ utilisation volontaire d’une nouvelle technologie sont 
determinees par deux perceptions : l’utilite pergue ( « le nouveau systeme 
va-t-il ameliorer ma performance au travail ? ») et la facilite d’ usage 
pergue (« quel effort devrais-je depenser pour apprendre et utiliser le 
nouveau systeme ? »). Differentes recherches ont permis un affinement du 
modele initial. L’utilite pergue semble en general avoir davantage de poids 
que la facilite d’usage, et elle peut etre influencee par des facteurs person- 
nels (age, experience, formation...), par l’entourage (attitude des pairs, 
attentes des superieurs. . . ) et par le systeme lui-meme (qualite des resultats 
foumis, pertinence par rapport au poste de travail. . . ). 

Si Ton diagnostique une telle origine a la resistance, il s’agit de faire 
evoluer les perceptions, par la formation et la documentation pour agir sur 
la facilite pergue, et par la communication et la participation a la concep- 
tion pour developper la perception de l’utilite. 

• La resistance est liee a {’organisation : il s’agit d’une problematique impact 
collectif. Le nouveau systeme modifie la division du travail, la coordination, 
la collaboration ou cooperation requise, les activites de controle... ce qui 
peut entrainer des oppositions. Deux approches explicatives ont ete proposees. 

Selon la perspective dite « socio-technique », certains acteurs manifestent 
une resistance parce qu’ils pensent (a tort ou a raison) que le nouveau 
systeme degradera leurs conditions de travail. Il s’agit, si Ton veutprevenir 
une telle resistance, de s’appuyer lors l’analyse des processus sur des princi- 
pes d’ergonomie (par exemple, appreciation du stress cause par certaines 
taches) et d’organisation des postes (par exemple, degre de responsabilite 
et d’autonomie), et de favoriser une participation a l’analyse des processus 
et a l’organisation des sites. 

Selon la perspective dite « politique », certains acteurs s’opposent parce 
qu’ils pensent (a tort ou a raison) que le nouveau systeme leur enlevera du 
pouvoir. L’opposition peut provenir de differents niveaux hierarchiques. 
Un cadre peut voir diminuer son pouvoir de decision et d’action, ou la 
taille du groupe place sous sa responsabilite. Un operationnel peut voir 

1. TAM : Technology Acceptance Model. F. D. Davis, « Perceived Usefulness, Perceived Ease Of 
Use, And User Acceptance », MIS Quarterly, 3, 3, 319-340, 1989. 
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reduire sa « zone d’incertitude », liee a la detention de son savoir-faire ou 
d’informations cles. Certains projets systeme d’information conduisent, 
pour atteindre des objectifs d’efficacite, a remettre en question des territoires. 
Cette situation doit etre prise en compte, en particulier dans l’analyse des 
risques et l’elaboration d’une strategic telles que developpees au chapitre 6. 
Seule la construction d’une vision d’un « bien commun », partagee par les 
acteurs en conflit, peut debloquer la situation : un engagement de la direction 
de l’entreprise et/ou la reference a des valeurs collectives sont des moyens 
d’y parvenir. 

Ces differents points de vue sur la resistance au changement peuvent faciliter 
la comprehension du contexte du projet et l’elaboration d’une strategic 
adequate. Ils apportent des elements a revaluation du potentiel de reussite lors 
d’un audit en cours de projet, tel qu’il est presente au § 6.4.3. 


5 A3 La place de la confiance 

Dans un projet systeme d’information, les acteurs de la conduite du changement 
sont ceux qui ont le pouvoir d’influencer la nature des changements en prepa- 
ration. L’equipe de projet, la direction de l’entreprise, la maitrise d’ouvrage, le 
chef de projet... en font partie. Les utilisateurs, dont le role et/ou le travail sera 
affecte par le futur systeme, ne sont que partiellement impliques dans les deci- 
sions sur le changement, sauf ceux qui ont ete selectionnes pour le mener ou y 
participer. Ceux qui restent exterieurs aux decisions sont dans une situation 
d’incertitude, c’est-a-dire qu’ils ne peuvent pas adopter un comportement fonde 
sur des elements qu’ils tiennent pour certains. En l’absence de certitude, le chan- 
gement peut apparaitre comme une menace et provoquer des attitudes de repli. 

C’est pourquoi la reussite d’une action de changement est souvent liee a 
l’etablissement d’une relation de confiance entre les acteurs de la conduite du 
changement et les utilisateurs. 

La confiance des utilisateurs peut etre definie comme la croyance dans le fait 
que les acteurs de la conduite du changement accompliront des actions qui auront 
des effets positifs pour eux et qu’ils n’ accompliront pas d’actions non desirables 
qui auraient des resultats negatifs. 

La confiance et l’engagement des utilisateurs interagissent dynamiquement. 
Si les acteurs soumis au changement ont confiance dans la competence de ceux 
qui organisent le changement, mais egalement dans leurs intentions, ils auront 
tendance a adopter une attitude positive face au projet. L’observation des actions 
contribue a developper ou diminuer la confiance dans les competences. Par 
ailleurs, la confiance dans les intentions tend a se renforcer au fur et a mesure 
que les faits confirment le bien-fonde de la decision de faire confiance. 
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La communication et les operations (^experimentation du futur systeme 
(prototype ou site pilote) peuvent developper la confiance. Cette disposition 
d’esprit ameliore l’engagement vis-a-vis du projet, notamment lors des formations 
ou de participations ponctuelles. II peut ainsi se creer une dynamique positive 
d’implication active des utilisateurs. 

5A.4 Les strategies de deployment 

On appelle « deployment » le fait de passer de l’ancien au nouveau systeme. Le 
terme, qui est aujourd’hui d’un emploi generalise, renvoie a une image selon 
laquelle le systeme, d’abord limite a une application informatique, change de 
dimension quand il est installe pour un fonctionnement operationnel. 

Differentes strategies peuvent etre adoptees, qui dependent de plusieurs facteurs : 

• La taille du projet ; 

• La modularity du systeme (independance des Sanctions ou des processus) ; 

• Le contexte (geographic, organisation...) ; 

• Les contraintes d’origine interne ou exteme (couts, calendrier, reglemen- 
tation, autres projets...) ; 

• Les risques de differentes natures (commercial, social, politique, image. . . ). 

La strategic comporte deux dimensions : le deployment structurel et/ou 
geographique, et le deploiement fonctionnel. Elle peut inclure un fonctionne- 
ment en double ancienne/nouvelle application pendant une certaine duree. Les 
differentes modalites retenues pour la premiere dimension sont souvent : 

• Couverture complete : tous les sites concemes changeront de systeme 
simultanement. 

• Couverture par region : le changement de systeme s’effectuera a des dates 
differentes selon les pays ou les regions. 

• Couverture par strates : les differentes entites dans l’organigramme (agences, 
succursales, concessionnaires...) rentreront dans le nouveau systeme a des 
moments differents. 

Le deploiement fonctionnel peut etre d’un bloc (l’ensemble des processus, 
variantes et fonctions) ou progressif. 

On appelle souvent « strategic big bang » la couverture complete et d’un 
bloc. C’est la solution la plus rapide, qui simplify la migration des donnees, mais 
en cas d’echec les consequences sont plus graves. Une couverture progressive par 
strates ou regions repartit les risques, mais fait cohabiter deux systemes. Un 
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deployment progressif est moins lourd a gerer, mais oblige a developper des 
passerelles entre ancien et nouveau systeme infonnatique. 

La strategic de deploiement est en partie liee a la strategic de projet, telle que 
presentee au § 6.4.2, et a des impacts sur les activites de la gestion du change- 
ment, notamment la communication, la formation, la migration et l’organisa- 
tion des sites. 

5.4.5 Les activites de la gestion du changement 

La gestion du changement comporte differentes activites, dont certaines visent 
les competences et les comportements des utilisateurs (communication et 
formation), et d’autres la construction d’un contexte permettant une utilisation 
reussie du nouveau systeme (documentation, migration, organisation des sites). 

• L’objectif de la communication est de reduire les risques d’un rejet qui aurait 
pour cause la non preparation ou la disinformation des acteurs concernes 
par le futur systeme. Les cibles peuvent etre internes (decideurs, utilisa- 
teurs, hierarchie locale, equipe projet, syndicats, Comite d’entreprise...) 
ou extemes (partenaires, foumisseurs, clients, grand public...). La cible 
influe sur le choix du media, le contenu du message et le calendrier de 
communication. Les operations de communication font generalement 
l’objet d’un suivi quantitatif et qualitatif, permettant d’ameliorer les 
operations ulterieures : 

• L’objectif de la formation est de faciliter la prise en main du nouveau 
produit par les utilisateurs et leur appropriation des nouvelles regies et 
procedures. La prise en compte du contexte humain, ainsi que des contraintes 
de nombre, de budget et de calendrier, conduit a l’etablissement d’une 
strategic de formation, c’est-a-dire des modalites (auto-formation, formation 
directe, formation de formateurs, accompagnement) et de la couverture. 
Elle est ensuite concretisee par un plan de formation (profils, themes, filieres, 
modules, supports, planning). 

• L’objectif de la documentation est de foumir aux utilisateurs une assistance 
apres passage au nouveau systeme. Elle peut etre un moyen d’auto formation 
pour certains. On peut distinguer la description des processus organisation- 
nels (roles, flux, documents, regies de gestion...), le manuel d’utilisation du 
logiciel (en mode debutant et en mode avance) et l’aide en ligne. 

• Formation et documentation peuvent etre completees par des actions 
d’ accompagnement lors des premiers temps du fonctionnement du nouveau 
systeme et de 1’ utilisation quotidienne du logiciel. Elies peuvent prendre la 
forme de personnes ressources a la disposition des differents sites ou bien 
d’un centre d’appels interne. 
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• V organisation des sites consiste, pour chaque entite structurelle et/ou 
geographique, a etudier de fagon detaillee les nouvelles procedures 
organisationnelles et a preparer la mise en place des moyens humains et 
materiels. Elle peut comprendre une analyse de l’organisation existante, 
un inventaire des materiels et un diagnostic des competences. Elle est a 
articuler avec le plan de communication et le plan de formation. Une dele- 
gation locale et une large implication des acteurs sont souvent preconisees. 

• L’objectif de la migration est de mettre en place les donnees (c’est-a-dire les 
informations gerees sous forme electroniques, fichiers, bases de donnees, 
bases de documents) necessaires au demarrage du nouveau systeme, en 
limitant la charge imposee aux utilisateurs, en reduisant les risques de 
pertes ou de discontinuity du service et en minimisant les perturbations 
des autres systemes. La migration comprend un volet technique (lie au 
passage d’une technologie a une autre) et un volet fonctionnel (ecarts 
dans la nature et la structure des donnees gerees entre l’ancien et le 
nouveau systeme). On s’appuie au maximum sur des outils logiciels du 
marche ou sur des programmes developpes specifiquement. Les utilisateurs 
peuvent cependant etre sollicites pour definir des regies (codification) ou 
pour des taches non automatisables (verification de la validite des 
donnees). Les consequences de la non qualite d’une migration peuvent 
etre importantes. Rappelons a cet egard les difficultes du systeme Socrate de 
la SNCF, dont les bases de donnees recensant les differentes destinations 
etaient incompletes, ce qui bloquait certaines ventes. C’est pourquoi il est 
recommande d’etablir un plan de migration, comprenant les actions a 
mener, leur planification et les responsabilites. 

• L ’ experimentation a pour objectif de reduire les risques de perturbations lors 
du passage au nouveau systeme. II s’agit de tester 1’ adequation et la perti- 
nence de ce qui a ete congu (produit et procedures) par rapport aux objec- 
tifs vises par le projet. L’experimentation peut se faire en mode simulation 
— on parle alors de « verification d’aptitude » — ou en mode reel sur un 
site pilote — on parle alors de « verification de service regulier ». Le choix 
d’un site d’experimentation obeit a des criteres de representativite du 
point de vue de l’activite du groupe (fonctions assurees, volumes traites, 
organisation), a des criteres de calendrier (disponibilite, absence de conflit 
avec des surcharges de travail) et a des criteres politico-strategiques (visi- 
bility du site, legitimite du site, influence sur les autres acteurs...). L’expe- 
rimentation se termine par un bilan, a partir d’indicateurs prealablement 
determines, suivi d’une decision : poursuite du deploiement, amenage- 
ment du deploiement incluant des corrections du systeme, ou bien, dans 
certains cas graves de rejet ou de dysfonctionnement, abandon de la mise 
en oeuvre du systeme. 
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5.5 ^ORGANISATION DU TRAVAIL DANS LES METHODES AGILES 


La dimension humaine est une preoccupation majeure pour les concepteurs des 
methodes agiles. Nous allons en indiquer les principaux points : une attention 
particuliere aux developpeurs, un souci d’integration des utilisateurs, des techni- 
ques pour faciliter l’expression des exigences, ainsi que des definitions de roles 
particuliers. 

55.1 Le management de I'equipe de developpeurs 

Les methodes agiles, particulierement orientees vers les projets de developpe- 
ment d’application, ont cherche des dispositions pour eviter ou reduire les 
problemes de competence, de communication ou de motivation chez les deve- 
loppeurs. 

Une des principales dispositions est la programmation en bindme (pair program - 
ming). La pratique de la programmation, longtemps consideree comme un art, a 
fait l’objet de dispositions methodologiques dans le sens d’une certaine indus- 
trialisation, visant a obtenir une qualite en grande partie independante des 
talents des developpeurs. L’approche par composants et la reutilisation, rendues 
possibles par les langages a objets, traduisent cette orientation. Cependant, 
meme si elle porte sur des elements plus petits, la programmation est le plus 
souvent restee une activite solitaire. 

Les methodes agiles, en particulier XP, ont rompu avec cette pratique et 
propose d’organiser le developpement en binomes, alliant souvent un deve- 
loppeur confirme avec un autre moins experiments. La qualite du logiciel 
devrait s’en trouver accrue pour deux raisons. La collaboration obligeant a expli- 
citer ses choix conduit a une ecriture plus simple et plus robuste. De plus, le 
regard d’autrui peut permettre de detecter plus rapidement d’eventuelles erreurs, 
abaissant ainsi leur cout de correction. Les binomes sont incites a de frequentes 
recompositions, a des fins de la circulation de connaissances par compagnon- 
nage. 

La programmation en binome a donne lieu a discussions, notamment sur le 
droit eventuel a refuser de travailler sur ce mode 1 . 

Un second principe, qui vise egalement le decloisonnement entre deve- 
loppeurs, est celui de propriete collective du code, chacun etant responsable de 
l’ensemble du logiciel et pouvant intervenir si necessaire sur des programmes 

1. Voir par exemple : J.Kendall et K.E.Kendall, « Agile methodologies and the lone systems 
analyst : when individual creativity and organizational goals collide in the global IT 
environment », Journal of Individual Employment Rights, 11,4, 333-347, 2004-2005. 
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ecrits par d’autres. Cela peut poser le probleme de la dilution de responsabilite, 
d’ou la recommandation d’entretenir regulierement l’idee d’engagement collectif 1 . 

Ce partage permet la mise en place d’une integration continue, c’est-a-dire que 
le resultat de chacune des taches elementaires est livre pour etre integre a un 
ensemble qui progressivement mettra en oeuvre le scenario, puis la fonctionna- 
lite demandee. Cette pratique evite les problemes d’incoherence que l’on 
rencontre frequemment lorsque Ton consolide les produits d’un travail morcele. 
Elle assure une coordination reguliere entre developpeurs. 

Un troisieme principe est l’attention aux conditions de travail des deve- 
loppeurs. Ces derniers, arrivant en bout de chaine dans les projets, sont souvent 
soumis a des tensions et depassements d’horaire pour tenir les engagements 
contractuels. Le Manifeste Agile s’inscrit dans une philosophic dite de develop- 
pement durable et considere que le rythme de travail adopte dans le projet doit 
pouvoir etre maintenu dans la duree. Le respect d’une charge de travail hebdo- 
madaire de 40 heures est souvent evoque. De plus, en contrepartie aux contraintes 
de collaboration, une attention particuliere devrait etre portee a l’agrement de 
l’environnement de travail et a l’harmonie du groupe par l’adoption participative 
de regies de fonctionnement collectif, voire d’activites extra-professionnelles de 
detente. 

5 ~ 5.2 L' implication des utilisateurs 

L’implication des utilisateurs poursuit un double objectif : une pertinence accrue 
du systeme produit et le maintien du projet dans un delai plus court que ce que 
l’on observe habituellement. 

Dire qu’un systeme d’information correspond a un besoin est une formulation 
qui masque une realite generalement plus complexe. En effet, les attentes 
sont souvent mal definies et emergent au fil du deroulement du projet. Elies sont 
susceptibles de changer au fur et a mesure que les commanditaires ont une vision 
plus claire de ce que les technologies sont susceptibles d’apporter ou parce que les 
conditions exterieures se sont modifiees. Par ailleurs, pour developper un systeme, 
il est quand meme necessaire a un moment donne de stabiliser des specifications : 
c’est ce que vise classiquement l’etablissement d’un cahier des charges. 

Les methodes agiles ont une position differente, considerant que l’explicita- 
tion exhaustive des exigences est a la fois couteuse et vouee a l’echec. Elies 
preconisent done de la remplacer par une participation soutenue des utilisateurs, 
qui accompagnent le travail des developpeurs. Ceci implique une localisation 


1. Voir, par exemple, A. Fruhling et G.J. De Vreede, « Field Experiences with eXtreme Program- 
ming: Developing an Emergency Response System », Journal of Management Information Sys- 
tems, 22, 4, 39-68, 2006. 
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geographique proche, des rencontres frequentes et une communication reguliere 
en face a face. Les utilisateurs ainsi impliques doivent avoir delegation pour 
representer la maitrise d’ouvrage, les decisions prises ne pouvant etre ensuite 
soumises a validation et remises en question par d’autres acteurs. 

Cette forme de participation, qui consiste a reagir immediatement a une 
fonction logicielle, permet d’orienter et d’ajuster les options de conception. Pour 
definir une architecture fonctionnelle, une autre forme de participation est 
privilegiee, celle qui consiste a travailler en session participative. 


5J>.3 Les techniques de travail en session participative 

Deux techniques, JRP et JAD, initialement promues par RAD visent a cons- 
truire des exigences partagees dans un groupe de commanditaires/utilisateurs. 
Elies ont ete reprises notamment par DSDM qui a elargi a une notion d’ atelier 
cooperatif et anime, sous le terme Facilitated workshop 1 . 

JRP signifie Joint Requirement Planning, definition participative des besoins, et 
JAD correspond a Joint Application Design, conception participative duplica- 
tion. Ces deux techniques furent proposees dans les annees 1980 par IBM, qui 
les a initialement mises au point pour ses projets d’informatisation internes, suite 
au mecontentement de ses utilisateurs jugeant etre trop peu associes a la defini- 
tion des specifications. Dans sa presentation initiale, IBM 2 utilise le terme JAD 
comme appellation globale des deux techniques JRP et JAD. Lorsque J. Martin 
les a integrees dans RAD, il les a considerees comme distinctes et complemen- 
taires. 

Le principe commun aux deux techniques est de reunir des utilisateurs pour 
les faire collaborer sur un objectif precis, de fagon intensive, en general pendant 
un ou deux jours, et dans un lieu les mettant a l’abri des sollicitations quotidien- 
nes. L’isolement temporaire et organise des acteurs peut favoriser l’emergence 
d’un esprit de groupe, oriente vers l’objectif commun. 

La session est conduite par un animateur, en position neutre par rapport aux 
enjeux, qui a pour role de surveiller les temps de parole, de recentrer vers l’objec- 
tif et de veiller a la participation de tous. Elle doit avoir ete preparee avec soin, 
pour obtenir une implication maximum des participants et un resultat solide. La 
tenue de sessions remplace des processus de decision/validation souvent lourds et 
longs quand plusieurs decideurs, ayant chacun un point de vue, en sont parties 
prenantes. C’est pourquoi les utilisateurs participant a une session doivent avoir 
delegation de decision. 


1. Voir http://www.dsdmfrance.com 

2. IBM Overview Pamphlet, JAD, « Joint Application Design », White Plains, New York, 1984. 
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De fagon plus precise, une session JRP vise a exprimer les grandes attentes 
d’un systeme partage par diffe rentes entites organisationnelles. La preparation 
est effectuee par les futurs participants, a l’aide d’un membre de Tequipe projet, 
par exemple le responsable de projet. Durant la session, chacun presentera son 
point de vue sur le systeme existant et ses manques ou disfonctionnements, 
selon un plan horaire rigoureusement etabli. L’animateur doit alors s’assurer que 
tous les participants partagent 1’ analyse proposee. Les travaux de preparation 
devraient permettre d’eviter que surgissent des contradictions irreductibles, et 
conduire a un bilan global du fonctionnement du domaine. Ensuite, chaque 
participant expose ses attentes, sous l’angle qui lui est propre. A la lumiere de ces 
elements, certains peuvent evoluer dans leur expression initiale. On arrive ainsi 
a construire une premiere vision du futur systeme. L’animateur s’attache a dega- 
ger un consensus sur le degre de priorite des fonctions. 

Dans le cas de JAD, la session vise a ajuster une architecture fonctionnelle ou 
une fonctionnalite concernant plusieurs entites organisationnelles, suite a une 
proposition par Tequipe projet. L’horaire d’une session JAD, meme s’il s’inscrit 
dans un cadre rigoureux, est plus souple que celui d’une session JRP. L’animateur 
adapte le deroulement en prenant en compte la dynamique du groupe. La 
presence simultanee de toutes les parties prenantes evite des allers-retours. En 
general, les conflits lies a des positions divergentes trouvent plus facilement une 
issue. L’utilisation d’outils de maquettage et/ou prototypage, ainsi que de moyens 
de visualisation et d’impression, renforcent l’engagement des utilisateurs dans 
une conception collaborative. 


5 . 5.4 Les roles dans les methodes affiles 

Chaque methode prevoit des roles specifiques visant les deux objectifs majeurs 
de qualite et delai. Ils orientent les relations entre commanditaires et produc- 
teurs, et organisent le travail de Tequipe. 

XP identifie six roles. 

Le programmeur a une double responsabilite de conception technique et de 
codage, pour des raisons de maintenabilite du code. II doit en effet construire son 
programme de fagon a ce qu’il puisse evoluer facilement par modification ou 
ajout de specifications. 

Le role du client consiste a exprimer ses exigences, sous forme de scenarios 
(user stories ) et en dialoguant avec les developpeurs, et a ecrire des jeux de tests 
fonctionnels qui seront utilises lors de la recette. 

Le testeur aide le client a elaborer des jeux de test. II peut intervenir dans les 
choix de conception pour eviter des options qui augmentent les difficultes de test, 
done les risques de non detection d’erreur. Ce role delicat necessite une bonne 
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connaissance du metier et des competences en developpement. II s’appuie le 
plus souvent sur des outils automatises. 

Le tracker est le gestionnaire du temps. II intervient notamment en debut de 
chaque iteration, lors de l’estimation, et ensuite il controle la progression par des 
echanges avec les developpeurs. Cette tache correspond a un pilotage operation- 
nel et quotidien du projet, dont nous decrivons les principes et techniques au 
chapitre 7. Le tracker n’a pas d’ autorite hierarchique. Son role est de maintenir 
le souci du respect des engagements par son activite quotidienne, mais aussi de 
detecter d’eventuels problemes suffisamment tot pour alerter le coach ou le 
manager. Chaque matin, il anime une breve reunion, appelee standup meeting car 
Ton reste debout, au cours de laquelle chaque developpeur annonce ce qu’il va 
faire durant la journee et d’eventuelles difficultes auxquelles il se heurte. 

Le coach a un role de soutien technique des membres de l’equipe, notamment 
lors des premieres iterations de livraison. Il peut recadrer certaines options de 
conception technique ou de codage, organiser des reunions de remue-meninges 
pour resoudre un probleme ou demander des changements d’un binome, en cas 
de blocage ou disfonctionnement. 

Le role du manager correspond a un role de chef de projet. Il est le responsable 
des developpeurs, qu’il soutient et encourage. Il doit rendre des comptes au 
client sur la base des informations foumies par le coach et le tracker. 

Ces roles peuvent etre combines. Un chef de projet peut ainsi reunir les roles 
de manager, tracker et coach. De fagon generale, on peut dire que les deux styles, 
participatif et par delegation, sont privilegies, mais qu’ils s’accompagnent d’un 
pilotage tres rigoureux qui demande une discipline quotidienne. 

Pour SCRUM, la notion d’equipe, au sens sportif du terme, est centrale. 
C’est pourquoi la methode n’identifie que trois roles dans l’equipe. 

Le proprietaire ( product owner) represente le client en ce qui conceme les 
specifications et les acceptations. 

Le scrum master est un capitaine d’equipe. Il anime au quotidien, recadre le 
projet en cas de difficult^, notamment en rappelant les priorites et en deblo- 
quant les situations. Ce role donne lieu a une certification. 

Tous les autres acteurs producteurs sont consideres comme des membres 
d’equipe, quelle que soit leur affectation specifique (architecte, developpeur, 
testeur, administrateur de base de donnees...). Les membres d’equipe disposent 
d’une certaine autonomie dans l’organisation de leurs travaux. 

SCRUM recommande comme XP une breve reunion quotidienne, appelee 
« melee » (scrum) car elle rassemble le proprietaire, membres de l’equipe et son 
capitaine. Animee par le scrum master, elle permet de repondre a trois 
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questions : quelle a ete la production de la veille ? quelle est la production 
prevue pour la joumee 1 qui rencontre un probleme ? Un tableau affichant ce 
qu’il reste a faire pour obtenir le livrable associe a l’iteration (le sprint) est alors 
mis a jour. Son role est d’encourager et de stimuler l’equipe de projet par la visua- 
lisation de la progression ou d’un pietinement dont il faut sortir. Appele Scrum 
Bumdown Chart, cet outil peut egalement etre utilise pour montrer plus globale- 
ment la progression du projet a chaque nouvelle iteration. 

Pour bien distinguer la place l’equipe, SCRUM parle parfois de « cochons » 
et de « poulets », en reference a une histoire imageant les differentes consequen- 
ces d’un role, et rapportee par K.Schwaber 1 . Un poulet et un cochon envisagent 
d’ouvrir un restaurant et cherchent un nom. « Pourquoi pas ‘CEufs et Jambon’ ? » 
suggere le poulet ? « Certainement pas, repond le cochon, car je serais engage 
dans l’affaire, alors que tu ne serais que conceme ». De fagon semblable, dit le 
concepteur de SCRUM, les membres de l’equipe, le Scrum master et le proprie- 
taire sont engages dans la production des livrables, alors que les autres parties 
prenantes du projet n’ont qu’une contribution marginale, et de ce fait ne 
doivent pas etre un poids pour le projet. Par exemple, ils sont invites a rester en 
retrait s’ils assistent aux reunions quotidiennes et a ne pas interferer dans les 
melees. Ils seront informes et consultes lors de la remise des livrables. Par exem- 
ple, un architecte systeme peut intervenir dans la phase de planification, ou les 
futurs utilisateurs dans la phase d’apres-jeu (cf. § 2.8.4). 

DSDM identifie neuf roles et affine davantage que XP ou SCRUM les posi- 
tions de la maitrise d’ouvrage 2 . 

Le sponsor executif correspond au plus haut niveau de decision du cote de la 
maitrise d’ouvrage, puisqu’il s’agit en particulier de financer le projet. 

Le visionnaire est le porteur du projet par rapport a des objectifs du metier. II 
en a une vision globale et intervient en particulier dans les sessions de concep- 
tion et de revision. Sa responsabilite s’etend a la mise a disposition d’utilisateurs 
necessaires au travail de la maitrise d’oeuvre. 

L’utilisateur ambassadeur peut correspondre a ce que RAD identifie sous le 
terme Chef de projet utilisateur. Affecte a temps plein sur le projet, il coordonne 
les demandes et apports des utilisateurs, et il travaille en etroite collaboration 
avec les responsables operationnels de la maitrise d’oeuvre. 

Le role d ’utilisateur conseiller est en general tenu par un futur utilisateur du 
systeme en cours de construction. Il n’intervient que lorsqu’il est sollicite pour 
fournir des informations sur le fonctionnement operationnel ou tester les proto- 
types d’un point de vue utilisation pratique. 


1 . Voir http://jeffsutherland.com/scrum/2004/05/scrum-pigs-and-chickens.html 

2. Voir http://www.dsdmffance.com 
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Le chef de projet est un role de gestionnaire de projet classique. II peut etre 
assure aussi bien par quelqu’un venant du metier ou ayant une experience tech- 
nique. 

Le coordinateur technique est garant de la coherence des travaux des deve- 
loppeurs, auxquels il apporte un soutien technique. 

Le chef d’equipe est un role plus managerial que celui de coordinateur techni- 
que. II porte la responsabilite de la livraison du systeme documente, et il assure 
l’interface avec les utilisateurs, en particulier pour l’organisation et la tenue des 
sessions de prototypage et ateliers. 

Les developpeurs ne sont pas obligatoirement organises en binome, ils peuvent 
rencontrer les utilisateurs, mais travaillent initialement a partir de documents de 
l’etude du metier. 

Le role de facilitateur intervient lors de la tenue des ateliers participates pour 
en assurer le travail preparatoire et l’animation. 

Le rapporteur est un role qui permet une transcription et une conservation des 
resultats des reunions et des ateliers. Dans RAD, ce role restreint aux sessions est 
appele scribe. 

On voit, a travers ces breves presentations, que selon la methode un interet 
different est porte a l’organisation du travail. DSSM se situe a un niveau englo- 
bant 1’ ensemble maitrise d’ouvrage — maitrise d’oeuvre. A l’inverse, SCRUM se 
focalise sur la notion d’equipe et cherche a augmenter son engagement. XP 
structure davantage les roles de producteurs, avec une exigence particuliere 
autour des tests. 

Ainsi s’acheve la presentation de differents aspects de la dimension humaine 
d’un projet. Nous les retrouvons en partie dans le management des risques 
presente au chapitre suivant, aussi bien dans l’analyse des facteurs de risque que 
dans la strategic et les dispositions visant a controler ces risques. 
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Le management 
des risques 


6.1 LES RISQUES DANS LES PROJETS SYSTEME D’INFORMATION 

6.1.1 L’ importance des risques dans les projets systeme d’information 

Les risques lies aux projets informatiques sont frequents et importants. 

Le Standish Group a mene en 1994 une premiere etude statistique sur plus de 
8 000 projets informatiques de toutes tailles et dans tous les secteurs d’activite, 
aux Etats-Unis. Le resultat a ete publie sur Internet sous le titre « Chaos 1 ». II en 
ressort qu’un tiers des projets sont abandonnes avant la fin, plus des trois quarts 
ont depasse leur budget et/ou delai et pres de la moitie n’ont pas completement 
atteint leur objectif ! D’autres etudes ont confirme le taux d’echec particuliere- 
ment eleve des projets systeme d’information. 

KPMG, dans une etude recente menee aupres de plus de 600 organisations 
dans 22 pays du globe 2 , constate que dans les 12 demiers mois, 49 % des organi- 
sations interrogees ont subi au moins un echec de projet informatique. De plus, 
86 % des organisations interrogees font etat d’un benefice reel inferieur de 25 % 
par rapport a celui attendu, chiffre que les analystes trouvent optimiste. 

Differents exemples temoignent des difficultes rencontrees. Citons notam- 
ment le celebre systeme Socrate de la SNCF, dont les dysfonctionnements ont 


1. On peut la trouver notamment sur : http://www.projectsmart.co.uk/docs/chaos-report.pdf ou 
sur la partie publique du site http://www.standishgroup.com. 

2. Global IT Project Management Survey 2005, telechargeable notamment sur http://www.kpmg.co.nz. 
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ete longuement commentes, ou le Plan informatique du ministere de la Justice 
abandonne en 1994 alors que 850 millions de francs y avaient ete consacres, qui 
ont donne « des resultats tres mediocres », selon le rapport de la Cour des comp- 
tes. Le projet Taurus de liaison informatique entre tous les acteurs financiers de 
la place de Londres est stoppe en 1993 apres dix ans d’efforts et une depense offi- 
ciellement evaluee a 400 millions de livres ; un projet analogue (projet Relit) a 
Paris a ete livre avec trois ans de retard. En 1996, le distributeur de produits 
pharmaceutiques Fox-Meyer a fait faillite, suite aux depenses considerables 
entrainees par la tentative d’installation du progiciel integre SAP. 

Ces quelques exemples ne sont pas des cas isoles, on en retrouve dans diffe- 
rents pays et secteurs d’activite, dans des entreprises ou des institutions reputees 
par ailleurs pour leur professionnalisme. Des enquetes recentes ont montre des 
ameliorations 1 , mais des progres restent a accomplir. Le management des risques 
est done de la plus grande actualite. 

6.1,2 La definition du risque 

Les assureurs definissent le risque par les consequences financieres d’un evene- 
ment redoute et sa frequence probable : 

Risque = Cout des consequences d’un evenement 
x frequence de cet evenement 

Si, par exemple, les consequences sont de 500 € et que l’evenement a une 
certaine probability de se produire trois fois tous les 5 ans, on dira que le risque 
est de : 

500 € x 3/5 = 300 € /an 

Cette definition n’est pas retenue dans le management des projets, ou Ton 
s’attache moins a quantifier les risques qu’a en faire une analyse fine. 

C’est pourquoi on prefere definir le risque comme la possibility qu’un projet ne 
s’ execute pas conformement aux previsions de dates d’achevement, de coiit et de speci- 
fications, ces ecarts par rapport aux previsions etant consideres comme difficilement 
acceptables voire inaeceptables [AFITEP, 2000]. 

Le PMBOK le considere comme une menace dont la concretisation, incer- 
taine, aurait un impact positif ou negatif sur au moins un objectif du projet tel 
que les delais, le cout, le contenu ou la qualite [PMI, 2003]. 

Le risque prend, en general, soit la forme d’un evenement (depart d’une 
ressource-cle, changement dans la reglementation...), soit celle d’une situation 
dans laquelle le projet se retrouve (parties prenantes divisees, equipe demotivee, 


1. Proje t plante, a qui la faute ?, 01 Informatique, n°1830, 7 octobre 2005, p.40-43. 
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perte de la maitrise du contenu du projet...)- La realisation des risques peut 
porter sur le processus ou sur le resultat. 

Dans le premier cas, il s’agit, par exemple, des cas de figure suivants : le projet 
n’aboutitpas ; il a consomme trop de ressources ; il a dure trop longtemps... 

Dans le deuxieme cas, on peut donner comme exemples : le systeme ne 
remplit pas la fonction attendue ; il n’est pas accepte par l’utilisateur ; son fonc- 
tionnement est trop couteux. 

6.1.3 Le management des risques 

Le risque resulte de l’incertitude attachee au projet, d’imprevus ou d’aleas. L’ incer- 
titude correspond a une « insuffisance d’information » qui empeche de prendre des 
decisions de fagon assuree. Les imprevus sont des "evenements qui n’ont pas ete 
envisages" [AFITEP, 2000]. notamment lors de l’analyse de risques. Les aleas sont 
des evenements « imprevisibles » ayant des consequences negatives sur les delais et/ 
ou les couts. 

Le management des risques consiste d’une part a reduire l’incertitude par une 
analyse plus approfondie des caracteristiques internes et environnementales du 
projet, d’ autre part a elaborer des strategies pour faire face aux risques les plus graves 
et/ou les plus probables. 

L’origine des risques etant l’incertitude, celle-ci peut aussi bien apporter des 
elements favorables que des elements defavorables. Cependant, dans la plupart 
des cas, on va s’attacher a eliminer ou a reduire les probabilites d’apparition 
d’elements negatifs et/ou a attenuer leurs consequences possibles sur le projet. 

La demarche generale de management des risques 1 comprend cinq etapes : 

1 . identifier les risques ; 

2. evaluer leur impact possible sur les couts, le delai et la qualite ; 

3. definir des actions ou prendre des dispositions aptes a reduire les risques 
juges inacceptables ; 

4. suivre les actions ou la mise en oeuvre des dispositions, et surveiller regu- 
lierement l’etat des risques ; 

5. capitaliser l’experience. 

On definit parfois un role specifique : le manager des risques, mais en general 
les responsabilites sont reparties au sein de l’equipe de projet. 

1. Cette demarche est representee notamment par le projet europeen RiskDriver, qui a eu comme 
objectif de promouvoir en Europe le management du risques et a donne lieu a l’outil Riskman : 
Opl Uk Limited, Riskman Reference Manual: The European Project Risk Management Metho- 
dology, Blackwell Pub, 1996. 
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Nous allons presenter le management des risques en nous focalisant sur deux 
aspects majeurs : l’analyse des risques (qui correspond aux etapes 1 et 2) et le 
controle des risques (qui correspond aux etapes 3 et 4). L’etape 5 sera abordee de 
fagon plus large au chapitre 7 (paragraphe 7.6). 

6*2 L'ANALYSE DES RISQUES 

6.2.1 Les differentes approches d’ analyse des risques 

Dans le domaine des systemes d’information, on a longtemps cru que le strict 
respect de dispositions methodologiques permettrait de mener les projets avec 
succes. C’etait mal comprendre les particularites de ces projets. 

Les trois principales sources d’echec sont la definition des besoins, V estimation des 
charges et la possibility de nombreux aleas dans le deroulement du projet. En effet, la 
plupart du temps les objectifs sont loin d’etre clairs et ce que Ton attend du futur 
systeme se clarifie progressivement ; or, parfois, au lieu de converger vers des speci- 
fications de plus en plus precises, on repart sur de nouvelles pistes ; ou bien l’on se 
retrouve dans l’incapacite d’assembler des elements de solution elabores separe- 
ment et d’en faire un tout coherent et repondant a l’objectif vise. Par ailleurs, 
l’estimation des charges n’est pas une science exacte : les ecarts de productivity 
individuelle peuvent etre importants et de nombreux facteurs peuvent conduire a 
un depassement de charge. De plus, divers evenements imprevus ou imprevisibles 
peuvent egalement avoir une incidence sur le deroulement du projet. 

Pour reperer et prevenir ces difficultes, differentes approches d’analyse des 
risques ont ete proposees. 

Nous allons d’abord presenter une approche generalisee d’identification des 
risques. Puis nous donnerons une deuxieme approche basee sur une liste de risques 
particuliers correspondant a des caracteristiques de projet. Ensuite, nous deve- 
lopperons l’approche par le profil de risque du projet. 

6.2.2 L’approche generalisee 

II s’agit de produire une liste de risques la plus large possible, et ensuite de selec- 
tionner ceux qui semblent les plus serieux. 

Differentes techniques de stimulation des idees peuvent etre utilisees : 

• des entretiens ou des seances de remue-meninges avec les parties prenantes 
du projet ; 

• la methode Delphi, en faisant appel a des personnes experimentees ; 

• l’analyse du projet selon une grille FFOM (forces, faiblesses, opportunites, 
menaces). 
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On peut eventuellement utiliser un diagramme cause-effet, dit d’Ishikawa, 
pour rechercher les sources d’un effet redoute (figure 6.1). 
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Figure 6.1 — Utilisation d'un diagramme cause-effet pour I'identification des risques 


Ensuite, on peut classer les risques en categories a l’aide d’une matrice, parfois 
appelee matrice de Pareto, selon leur probabilite d’occurrence et les impacts 
previsibles sur le projet (figure 6.2). 


Impact 

Probabilite occurrence 

Faible 

Important 

Elevee 


risques inacceptables 

Faible 

Risques mineurs 



Figure 6.2 — Matrice de probabilite/impact 


6.2.3 L’approche par les types de risques recenses 

Des listes de risques ont parfois ete etablies. Nous allons donner deux exemples 
de recensement raisonne de risques propres aux projets informatiques. 

Le premier a ete propose par Euromethode, dont nous presentons le cadre au 
chapitre 16 consacre aux associations professionnelles et aux normes. Le second 
resulte d’un travail mene au sein de l’AFITEP. 

Euromethode considere que les risques du projet peuvent provenir de diffe- 
rentes sources (figure 6.3). Dans les phases amont, les specifications peuvent etre 
difficiles a elaborer (systeme d’information) pour differentes raisons. Ensuite, on 
peut buter sur des obstacles dans la construction du systeme informatique. Diffe- 
rentes activites du projet peuvent etre entachees d’incertitude. Les liens structurels 
du projet avec d’autres ou entre les parties prenantes presentent parfois des 
caracteristiques difficiles a gerer. Enfin la taille et la competence de l’equipe de 
projet, ainsi que les caracteristiques des outils mis en oeuvre dans le projet sont 
egalement des causes de difficultes. 
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systeme 
d’ information 

complexite de l’information, complexite des processus 
metiers, incertitude sur la competence des utilisateurs, 
incertitude sur la stabilite des specifications. . . 

systeme 

informatique 

complexite de la technologie cible, complexite des algo- 
rithmes... 

projet : les activites 

complexite de la migration, incertitude liee aux sous-traitants. . . 

structure 

nombre d’ interfaces avec d’autres projets, degre de formalisation 
de la relation MOA-MOE 

acteurs 

nombre d’ acteurs directement impliques, competences 
de l’equipe de projet. . . 

technologie 

complexite de V atelier de genie logiciel, disponibilite 
de l’outil de gestion de projet 


Figure 6.3 — Les sources de risques selon Euromethode 


Plus recemment, la commission informatique de l’AFITEP 1 a propose une 
typologie des projets informatiques et une liste des risques principaux associes a 
chaque type de projet. 

Ainsi, un projet peut etre caracterise par un type d’objectif, un type de cible 
et un type de solution envisage (figure 6.4). 



Definition 

Exemples 

Objectif 

Strategic 

11 s’agit d’un projet dont les enjeux 
relevent de la Direction generale. 

11 s’appuie souvent sur une techno- 
logie novatrice. 

Messagerie dans les annees 
1970 

GPAO dans les annees 1980 
Commerce electronique 

Efficience 

11 s’agit d’un projet de remplacement 
ou d’outillage d’un processus existant, 
en vue d’accroitre la productivite. 

11 s’appuie souvent sur des techno- 
logies eprouvees. 

Mise en place d’un work- 
flow 

Mise en place d’un progi- 
ciel de paie 

Automatisation de gestion 
de stock 

Obligation 

11 s’agit d’un projet lie a une obliga- 
tion exterieure, legale ou de fait. 

11 s’appuie souvent sur une techno- 
logie banalisee. 

Projet an 2000 
Projet Euro 

Fusion/absorption d’entre- 
prise 


Figure 6.4 — Criteres de classification des projets. 


1 . Pour plus de details, voir la : 


: de l’AFIPEP : La Cible, n° 80 et n° 81 (dec. 1999 et janv. 2000). 


6.2. L’analyse des risques 




Definition Exemples 

Cible 

Client 

Le resultat du projet accroit, pour les 
clients, la valeur ajoutee de T organi- 
sation (entreprise, administration, 
association. . 

Le client peut etre l’usager, le 
consommateur, le prescripteur, 

T adherent 

Bon de commande sur 
Internet 

Informatique embarquee 
TGV 

Gestion de la relation client 

Support 

Le resultat du projet ameliore 
le fonctionnement interne de 
T organisation. 

L’ impact sur le client est indirect. 

Progiciel comptable 

Transversal 

Le resultat du projet touche 
1’ ensemble de 1’ organisation. 

11 s’agit principalement de la mise 
en place d’outils communs. 

Messagerie 
Systemes bureautiques 
Intranet 

Type de solution 

Progiciel 

applicatif 

Projet de mise en place d’un produit 
logiciel standard commercialise par 
un editeur. 

CAO, gestion integree, 
Gestion documentaire 
electronique 

Type de solution (suite) 

Developpement 

applicatif 

Projet de conception et de develop- 
pement d’un logiciel specifique dont 
le code source appartient a 1’ entre- 
prise (meme si le developpement est 
sous-traite en tout ou partie). 

Creation d’un site web 
commercial 
Gestion de bourses 

Integration de 
systemes 

Projet d’assemblage et d’interface 
des differents elements materiels et 
immateriels. 

Projet « Socrate » de la 
SNCF et son materiel 

Maintenance 

evolutive 

Projet devolution d’un systeme 
existant (materiel ou logiciel). 

Nouvelle version d’un 
logiciel interne 

Infrastructures 

techniques 

Projet concemant la mise a disposi- 
tion d’une ossature technique. 

Deployment de reseau, 
Systeme de securite 


Figure 6.4 — Criteres de classification des projets. (Suite) 
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Selon les valeurs prises par ces trois criteres, des risques ont pu etre frequem- 
ment observes (figure 6.5). 


Objectif du projet 

Risques 

Strategie 

Faible niveau d’ implication de la Direction Generate 
Changement de l’environnement 
Non-remise en cause de l’existant 
Communication deficiente 

Efficience 

Appropriation insuffisante du SI par les utilisateurs 
Sous-estimation globale du projet, minimisation des couts 
Derive technologique 

Obligatoire 

Manque d’attractivite du projet 
Cahier des charges incomplet 
Non-respect des delais 

Cible du projet 

Risques 

Client 

Mauvaise perception des attentes client 
Non-remise en cause du fonctionnement interne 
Deterioration de la performance de l’organisation 

Support 

Non-remise en cause de l’existant 
Sous-estimation des travaux 
Modification de l’environnement 
Rejet par les operationnels 

Cible du projet 

Risques 

Transversal 

Definition insuffisante de l’objectif 
Structuration inadequate du projet 
Sous-estimation de l’utilisation 

Type de solution 

Risques 

Progiciel applicatif 

Non-perennite du produit selectionne 

Sous-estimation de la charge/complexite de l’integration 

Pas de remise en cause de l’existant 

Gestion du changement deficiente 

Pas de prise en compte des evolutions du progiciel 

Developpement 

applicatif 

Insuffisance du cahier des charges (besoins et solutions) 
Manque de competences ou de perennite du prestataire 

Integration 
de systeme 

Erreurs dans le choix des composants 
Sous-estimation des travaux de migration et d’interfa§age 


Figure 6.5 — Liste des risques principaux selon le type de projet. 
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Type de solution 


Risques 


Maintenance 


Absence ou indisponibilite des ressources (humaines et/ou 
documentaires) 

Mauvaise analyse d’ impacts des modifications envisagees 


Infrastructure 

technique 


Reduction du projet a sa dimension technique 
Technologie incompatible avec la maturite technologique de 
l’entreprise 


Figure 6.5 — Liste des risques principaux selon le type de projet. (Suite) 

Cette typologie represente, pour le chef de projet, une aide a ^identification 
des risques de son propre pro jet. 

6,2 ,4 L’approche par le profit de risque 

Cette approche s’apparente a la precedente, dans le sens ou elle s’appuie sur une 
liste de facteurs de risque reconnus, mais elle approfondit l’analyse a l’aide de 
criteres et metriques pour obtenir une mesure de chaque source de risque, ce qui 
permet de dresser le profil du projet. 

Les facteurs de risque 

L’origine des risques pouvant peser sur une situation de projet est variee, cependant 
six facteurs, qui caracterisent le projet, jouent un role determinant : 

1 . la taille du projet ; 

2. la difficult^ technique ; 

3. le degre d’integration ; 

4- la configuration organisationnelle ; 

5. le changement ; 

6. l’instabilite de l’equipe de projet. 

La taille du projet est un facteur retenu par la plupart des auteurs. Le risque est 
lie aux limites de l’individu. Un grand projet signifie une large etendue du 
domaine couvert, qui impose une division du travail entre un nombre eleve de 
personnes. La semi-autonomie necessaire a l’avancement de chaque sous- 
groupe conduit naturellement a un morcellement. En l’absence d’un dispositif 
imposant une synthese et un depistage des incoherences, il y a perte de la 
maitrise du processus de production qui ne converge plus et n’est plus sous 
controle. 
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La majorite des echecs de projet systeme d’information n’ont pas une cause liee 
a la difficulte technique ; cependant ce facteur est souvent cite comme generateur 
de risque. II correspond a une nouveaute technologique ou bien a une difficulte 
technique provenant des contraintes imposees au projet. Ce sont souvent des 
contraintes de performance. Le risque est celui de l’absence de competences 
techniques necessaries, qui penalise la production. 

Le degre d’ integration agit sur la complexity du projet, puisqu’il mesure le degre 
de dependance ou d’autonomie du ffitur systeme. Des flux nombreux et varies 
entre le systeme d’information que l’on developpe et les autres systemes d’infor- 
mation de l’entreprise rendent plus difficile ^identification claire des impacts de 
choix de conception. D’ autres entries, d’autres projets, d’autres equipes de deve- 
loppement sont concemes, ce qui augmente le nombre d’acteurs du projet. 

La configuration organisationnelle est un facteur correspondant a l’etendue de 
l’entreprise qui est touchee par le projet (organizational scope). Le risque provient 
de la lourdeur des procedures de participation et de decision quand plusieurs 
grandes entites (des directions, par exemple) sont parties prenantes du projet. La 
production en est ralentie. S’y ajoutent d’eventuels motifs de conflits, qui 
alimentent un processus politique latent, bloquant les prises de decision. 

Le changement vise par le projet signffie que les systemes de gestion et/ou 
d’organisation existants ne peuvent pas etre pris comme reference stable et que 
l’effort de conception/innovation va etre important. L’ abandon du statu quo cree 
une instability qui favorise le processus politique. Les risques de rejet ou de 
mauvaise definition du futur systeme sont eleves. 

L 'instabilite de I’equipe de projet, quelle qu’en soit la cause, pose le probleme du 
transfert de connaissances : les concepteurs engrangent un ensemble de connais- 
sances implicites sur le projet et son domaine que des modeles formalises ne suffi- 
sent pas a transmettre. Cette connaissance est a reconstituer et les erreurs 
d’interpretation peuvent avoir des consequences sur les delais et sur la coherence 
de la conception. 

La grille d’analyse des risques et le profit de risque d’un projet 

Ces differents facteurs de risque ne peuvent pas etre geres de fagon semblable. 
Leur variete requiert une analyse du profil de risque, dans laquelle chaque type 
reste identifie. Chaque facteur est precise par plusieurs criteres, et chaque critere 
est mesure sur une echelle de 1 a 4 par des metriques. La grille detaillee est 
donnee en annexe C. Elle est utilisee au chapitre 9, pour illustrer la mise en 
oeuvre de l’analyse de risque. 

• La taille du projet est mesuree par sa charge estimee, sa duree prevue et 
Pampleur de sa couverture fonctionnelle. 
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• La difficulte technique est mesuree par l’experience capitalisee de l’entre- 
prise sur les techniques a utiliser, la diffusion de ces techniques sur le 
marche, les contraintes de performance et l’existence de la direction infer- 
matique interne. 

• Le degre d’integration est mesure par les flux entre la future application et 
d’autres applications, ainsi que par le nombre d’ applications connexes en 
cours devolution. 

• La configuration organisationnelle est mesuree par le nombre de Direc- 
tions assurant la maitrise d’ouvrage, l’appui de la Direction Generale, ainsi 
que par 1’ implication et la perennite du promoteur. 

• Le changement est mesure par les degres devolution fonctionnelle, orga- 
nisationnelle et technique, ainsi que par le nombre de sites concernes et 
les eventuels impacts sociaux. 

• L’instabilite de l’equipe de projet est influencee par plusieurs criteres : la 
duree du projet, la part de sous-traitance de la maitrise d’oeuvre, le degre 
de rotation ou de mobilite du personnel dans l’entreprise, la qualite des 
relations entre maitrise d’ouvrage et maitrise d’oeuvre, l’attrait des tech- 
niques utilisees, la conjoncture du marche de l’emploi et l’image du 
projet. 

Ces metriques permettent d’etablir le profil de risque du projet, dont un exemple 
est donne a la figure 6.6. 


Nature du risque 

Degre du risque pour le projet 
0 12 3 4 

Taille du projet 


Difficulte technique 

Degre d’integration 

Configuration organisationnelle 

Changement 

Instability de l’equipe de projet 


Figure 6.6 — Profil de risque d’un projet. 
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Si plusieurs risques majeurs apparaissent sur le profil, leur reduction est une 
condition de la reussite du projet. C’est la premiere mesure du controle des risques, 
qui est developpe au paragraphe 6.4. 


LE PLAN DE MANAGEMENT DU PROJET 

L’identification des risques conduit, en general, a prendre des mesures qui vont 
modifier le contenu du projet, voire dans certains cas le contenu du produit avec 
l’accord du commanditaire. Tous les aspects du projet, tel qu’ils ont ete planifies, 
peuvent etre touches. Lorsque le projet est gere de fagon rigoureuse, les resultats 
de la planification, et leurs modifications ulterieures, sont consignes dans un 
document appele le plan de management du projet. 

Celui-ci prend en compte l’unicite de tout projet et represente le passage de 
la theorie a la pratique. Les differents choix issus de la planification (decoupage, 
delais, ressources, contenu...) sont done traduits dans un plan propre a chaque 
projet. Par exemple, le choix d’un modele de developpement en cascade doit 
preciser le nombre et le contenu des etapes ; les modalites de participation 
doivent specifier les acteurs concrets avec leurs roles... 

La norme ISO 10006 definit le plan de management de projet comme un 
document qui specifie les exigences permettant d’atteindre les objectifs du projet, et 
comprend les aspects qualite, ressources, planning, budget et gestion des risques. 

L’AFITEP et l’AFNOR precisent que le plan de management de projet (PMP) 
est un document essentiel etabli au debut du projet sous l’ autorite du chef de projet et 
qu’il comprend la description de l’objectif, l’expose des moyens necessaires au 
cours du projet, les activites envisagees, 1’ analyse des risques et les moyens pour 
les traiter, le planning general et le budget, les procedures et normes qui s’appli- 
quent au projet. Ce plan peut etre revise en fonction des evolutions du projet, mais la 
tragabilite doit etre strictement assuree [AFITEP, 2000]. 

Le PMBOK attire 1’ attention sur le caractere officiel de ce plan entre les 
parties prenantes. II est en effet defini comme un document formel et approuve qui 
definit les modes d’ execution, de surveillance et de maitrise du projet [PMI]. Tous les 
aspects planifies peuvent s’y retrouver dans des plans subsidiaires (plan qualite, 
echeancier...). 

La prise en compte de l’analyse des risques, e’est-a-dire leur controle, conduit 
souvent a modifier le plan de management du projet. Nous allons d’abord 
presenter de fagon generale les types de reponses aux risques et nous ciblerons 
ensuite sur la prise en compte des risques dans les projets systeme d’ information, 
suite a l’etablissement du profil de risque decrit au paragraphe 6.2.4. 
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6.4 LE CONTROLE DES RISQUES 

Le controle des risques suppose souvent de faire appel a des solutions imagi- 
natives. On peut citer a ce propos la « Pensee laterale » proposee par le medecin 
et psychologue Edward de Bono 1 . Cette technique de recherche de solution 
consiste a approcher le probleme non pas de face (verticalement), selon des 
schemas classiques, mais sous differents angles (lateralement), en osant des solu- 
tions peu orthodoxes. Le principe general est le suivant. Apres avoir tente de 
reconnaitre les idees dominantes ou polarisantes, c’est-a-dire qui orientent vers 
une meme categorie de solutions, on recherche de nouvelles fagons d’envisager 
les choses. Certaines idees provocantes ( provocative operation ) peuvent ainsi etre 
enoncees, non pour donner une solution, mais pour modifier la vision des choses 
et introduire une certaine liberte, favorisant ainsi le relachement du controle de 
la pensee verticale. 

Sans nous etendre davantage sur les techniques de creativite, nous allons 
passer en revue les mecanismes classiques de reponse aux risques. 

6.4.1 Les strategies generiques de reponse aux risques 

On distingue cinq types de comportement face a un risque identifie : eviter, 
transferer, attenuer, accepter et elaborer une reponse conditionnelle. 

Eviter 

On modifie le plan de management du projet pour eliminer la menace. Le risque 
a done disparu. 

Par exemple, si le risque majeur provient de la nouveaute technologique, on 
evite le risque en se repliant sur une technologie eprouvee. On peut aussi acquerir 
de l’experience, c’est-a-dire former l’equipe de projet concemee par les aspects 
techniques, de fagon a lever les incertitudes. Si la menace vient d’un sous-traitant 
qui pourrait se montrer defaillant (delai, qualite), on l’evitera en renongant a 
extemaliser le developpement. Si enfin Ton craint le refus du systeme par les utili- 
sateurs, on peut chercher a l’eviter en associant les utilisateurs a la conception. 

Transferer 

On modifie le plan de management du projet pour detourner la menace et ses 
consequences possibles sur un tiers. Le risque n’a done pas disparu. 

Par exemple, si la menace est de depasser le budget, un transfert pourra 
consister a sous-traiter au forfait 2 (pour le client) et inversement a travailler en 


1. E. de Bono, Au service de la creativite dans I’entreprise : la pensee laterale, EME, 1973. 

2. Les aspects concemant la sous-traitance sont decrits au chapitre 7. 
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regie (pour le maitre d’oeuvre). Si le sous-traitant risque de depasser le delai, on 
peut utiliser des clauses contractuelles pour se garantir financierement (penalites 
de retard). Si Ton craint des vols de materiel utilise sur le projet, on peut prendre 
une assurance moyennant une prime : les consequences financieres seront supportees 
par l’assureur. 

Attenuer 

On modifie le plan de management du projet pour reduire la probability et/ou les 
consequences d’un evenement a risque. C’est une strategie ffequemment utilisee. 

Par exemple, si l’on redoute une faible qualite des livrables logiciels, on peut 
prevoir d’augmenter le nombre de tests. S’il peut y avoir des erreurs de compre- 
hension des specifications detaillees par le client, on peut reduire ce risque en 
elaborant un prototype ou mieux gerer ses consequences en prevoyant des ressources 
supplementaires au moment de la recette pour effectuer des ajustements. 

Accepter 

On ne modifie pas le plan de management du projet et on accepte le risque tel qu’il 
se presente, soit parce qu’on ne pense pas qu’il va se realiser ou qu’on ne redoute 
pas ses consequences, soit parce qu’on ne trouve pas d’autre reponse. 

On distingue deux formes d’acceptation. L’ acceptation passive consiste a ne 
rien faire du tout et a prendre des mesures a chaud en cas de concretisation du 
risque, c’est-a-dire elaborer le cas echeant un plan dit « palliatif ». L’acceptation 
active consiste a prevoir une provision pour faire face aux aleas, par exemple une 
part de budget ou des ressources qui seront utilises si le risque se realise. 

Elaborer une reponse conditionnelle 

Sans modifier le plan de management du projet, on prepare un plan annexe qui 
ne sera mis en oeuvre que sous certaines conditions de realisation du risque. 
Celui-ci est appele « plan de secours », il modifiera le deroulement du projet. On 
peut, par securite si les consequences du risque peuvent etre tres graves, preparer 
egalement un « plan de repli » au cas ou le plan de secours serait inefficace. 

Par exemple, si l’on craint que le foumisseur de materiel ait du retard, on peut 
prevoir dans un plan de secours une action de pression sur le foumisseur, et en 
repli un nouvel echeancier. 

Pour controler les risques, il s’agit souvent de prendre en compte un ensemble 
de risques dans une strategie globale que l’on peut appeler « strategie de projet ». 

6.4.2 La strategie de projet 

Apres etablissement d’un profil de risque et une reduction eventuelle, le chef de 
projet doit elaborer une strategie de projet, ce qui signifie : 
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• choisir un modele de cycle de vie et l’adapter au projet ; 

• mettre en place un dispositif de coordination, avec ses composantes 
personnelles et impersonnelles ; 

• choisir les modalites de participation des utilisateurs ; 

• mettre en place un dispositif de controle, c’est-a-dire un tableau de bord 
permettant le pilotage du projet. 

Les modeles de cycle de vie ont ete decrits au chapitre 2. La coordination et 
la participation ont ete presentees au chapitre 5. Le dispositif de controle figure 
au chapitre 7 qui decrit les facettes du pilotage. 

Le risque lie a la taille se gere de trois fagons. 

Si la visibility est faible, les engagements doivent etre limites mais precis. Le 
modele de developpement privilegie est celui de la spirale : chaque cycle compre- 
nant une analyse du risque permettra un affinement ou une redefinition des objectifs. 

Pour controler l’avancement d’une equipe importante, il faut s’appuyer sur un 
dispositif de coordination formelle et sur un systeme formalise de controle de 
l’avancement du projet, comme une necessaire extension de la memoire humaine 
individuelle. 

Dans la maitrise de la coherence, la coordination personnelle qui trouve ses 
limites devant le nombre, doit etre soutenue par des moyens formels, comme une 
administration de systeme d’ information. 

Le risque technique, s’il provient de la complexity de mise en oeuvre d’un 
outil, se gere comme un probleme de chargement, classique en gestion de projet 
industriel : il s’agit de reperer et de faire intervenir la bonne ressource au bon 
moment. Si les besoins sont stables et que le risque majeur est lie a la program- 
mation, on choisira un modele de developpement en cascade avec deux etapes 
majeures : specifications precises, suivies d’une etape programmation sans modi- 
fication des specifications. Sinon, un modele en W est preferable, le prototype 
permettant de stabiliser les besoins. 

Si le risque decoule de la nouveaute, il faut alors utiliser un modele en W, 
dont la premiere partie est axee sur la maitrise de l’outil ou de la performance. 

Le risque lie a 1 ’integration appelle une coordination personnelle en renfort 
d’un systeme d’information sur le futur systeme. Un exemple de ce dernier 
(administration des donnees) est presente au chapitre 5. Le modele de develop- 
pement en V facilite l’integration modulaire. 

Le risque lie a la configuration organisationnelle (les utilisateurs) conduit a recher- 
cher un consensus decisionnel, sur un champ qui pourra etre limite. La participation 
a pour objectif la prise de decision. Le modele du cycle RAD peut la favoriser. 
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Le risque lie au changement se gere par la participation des differents acteurs. 
II faut user de modalites adaptees a l’objectif, qui peut etre la creativite (concep- 
tion d’un nouveau systeme), 1’ adhesion (eviter les rejets) ou la prise de decision. 
Si les contraintes de budget et delai sont faibles et s’il n’y a pas de probleme 
d’integration, alors le modele de developpement evolutif sera le plus adapte. 

Le risque lie a Vinstabilite de I’equipe de projet (les concepteurs) peut etre limite a 
la fois par un systeme d’ information sur le futur systeme (documentation de projet) 
et par une coordination personnelle de type supervision directe qui favorise la 
transmission des connaissances. 

Dans le cas particulier ou Ton veut mener le projet dans un delai tres bref, sans 
sacrifier la qualite, une methode agile sera privilegiee. Un tel choix est examine 
du point de vue des risques au § 6.5. 

Ainsi, le developpement d’un systeme d’information comporte trois processus 
(figure 6.7) : l’un, rationnel, vise la production d’une application ; le deuxieme, 
politique, cherche a ce que les decisions necessaires soient prises ; le troisieme, 
psychologique, gere les changements individuels et sociaux lies au nouveau 
systeme d’information. 



^ Plan de management du projet J 


Figure 6.7 — Elaboration d’un plan de management de projet. 
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Les processus sociaux (decision, motivation) introduisent pour le meme probleme 
une variete importante. La strategic de projet doit articuler les trois processus. 
Ainsi, certaines taches de production (elaborer un modele, construire un proto- 
type...) pourront-elles parfois avoir un objectif politique ou social. 

6.4.3 L'audit en cours de projet 

Le controle des risques peut conduire a une reevaluation periodique de la situa- 
tion du projet au regard des risques, notamment sous forme de revue structuree 
a mener en interne par l’equipe de management de projet. Nous presentons 
ci-dessous un exemple d’une telle demarche d’audit du projet sous l’angle des 
risques. 

Le Standish Group a propose, a partir d’une soixantaine d’interviews appro- 
fondies menees avec des responsables informatiques, une grille d’e valuation du 
potentiel de reussite d’un projet en cours 1 . Cette grille comprend dix criteres, 
pesant chacun d’un certain poids dans la reussite du projet (figure 6.8). II appa- 
rait ainsi que l’engagement de la maitrise d’ouvrage, utilisateurs et decideurs, 
avec une definition claire des besoins pese pour moitie dans le succes d’un projet. 


Criteres de reussite 

Poids du critere 

Implication des utilisateurs 

19 

Soutien de la hierarchie 

16 

Definition claire des besoins 

15 

Plan de developpement correct 

11 

Attentes realistes 

10 

Decoupage du projet en petites etapes 

9 

Competences dans l’equipe de projet 

8 

Appropriation du projet par les acteurs du projet 

6 

Vision claire de la raison d’etre et des objectifs du projet 

3 

Productivite et motivation de l’equipe de projet 

3 


100 


Figure 6.8 — Criteres de reussite d’un projet. 


1. On peut la trouver sur la partie publique du site http://www.standishgroup.< 
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Pour determiner la valeur de ces criteres lors de 1’ audit d’un projet particulier, 
les auteurs de l’etude proposent une serie de questions qui precisent la significa- 
tion de chaque critere. Chaque question pese d’un poids equivalent dans revaluation 
du critere. 

1. Implication des utilisateurs 

- A-t-on reellement les utilisateurs qu’il faut ? 

- Les a-t-on impliques suffisamment tot et suffisamment souvent ? 

- Les relations avec les utilisateurs sont-elles de bonne qualite ? 

- A-t-on facilite leur implication ? 

- A-t-on reellement trouve leurs besoins ? 

2. Soutien de la hierarchie 

- A-t-on mobilise les responsables cles ? 

- La reussite du projet est-elle un enjeu important pour les responsables cles ? 

- L’echec est-il acceptable ? 

- A-t-on un plan de projet bien defini ? 

- Y a-t-il un enjeu fort pour l’equipe de projet ? 

3. Definition claire des besoins 

- A-t-on une vision concise de la strategic, des enjeux, du court, moyen et long terme ? 

- A-t-on fait une analyse des fonctions attendues ? 

- A-t-on fait une analyse de risque l 

- A-t-on fait un dossier d’opportunite ? 

- A-t-on defini des metriques pour evaluer la reussite du projet ? 

4. Plan de developpement correct 

- A-t-on formalise une description du projet ? 

- A-t-on formalise une description de la solution ? 

- A-t-on une equipe de projet adequate ? 

- Les specifications sont-elles stabilisees ? 

- A-t-on etabli une planification avec des etapes realistes ? 

5. Attentes realistes 

- A-t-on des specifications claires ? 

- A-t-on etabli des priorites entre les besoins ? 

- A-t-on fait un decoupage en petites etapes ? 

- Peut-on gerer le changement ? 

- Peut-on faire un prototype ? 

6. Decoupage du projet en petites etapes 

- Utilise-t-on la regie des 80/20 pour se centrer sur les 20 % des fonctions qui vont 
satisfaire 80 % des besoins des utilisateurs ? 

- Utilise-t-on une conception descendante ? 

- A-t-on arrete des dates butoirs ? 

- Utilise-t-on un outil de prototypage ? 

- Peut-on mesurer l’avancement ? 

7. Competences de l’equipe de projet 

- A-t-on une bonne connaissance des competences requises ? 

- A-t-on rassemble les bonnes ressources ? 
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- A-t-on defini un plan de formation ? 

- A-t-on prevu des incitations pour motiver l’equipe ? 

- L’equipe va-t-elle rester jusqu’a la fin du projet ? 

8. Appropriation du projet par les acteurs du projet 

- Les roles ont-ils ete correctement definis ? 

- L’organisation a-t-elle ete clairement annoncee ? 

- Chaque acteur du projet connait-il son role et ses responsabilites ? 

- Les incitations pour motiver les acteurs du projet contribuent-elles a la reussite du 
projet ? 

- Y a-t-il un engagement de tous les acteurs du projet ? 

9. Claire vision de la raison d’etre et des objectifs du projet 
-Tous les acteurs partagent-ils la meme vision du projet ? 

- Cette vision est-elle en phase avec les objectifs de l’entreprise ? 

-Les objectifs du projet sont-ils realistes et peuvent-ils etre atteints ? 

- Les objectifs du projet sont-ils mesurables ? 

- A-t-on prevu des controles de bons sens, honnetes et reguliers ? 

10. Productivity et motivation de l’equipe de projet 

- A-t-on mis en place des incitations (primes, augmentations, promotions) ? 

- Se concentre-t-on sur les livrables annonces ? 

- Chacun s’est-il approprie le projet ? 

- Y a-t-il un travail d’equipe ? 

- A-t-on bad un climat de confiance ? 

La somme des valeurs ponderees de chaque critere donne le potentiel de reus- 
site du projet. Cette grille d’analyse permet, le cas echeant, de redresser la barre 
et de mettre en oeuvre des actions pour augmenter les chances de succes. 

6.5 LES METHODES AGUES ET LA GESTION DES RISQUES 


Pour etudier la relation entre management des risques et methodes agiles, on 
peut d’abord se demander si les preconisations agiles modifient le profil de risque 
du projet, tel qu’ expose au § 6.2.4. On peut aussi examiner si leur utilisation 
pourrait avoir un effet sur les facteurs de succes du projet presentes au paragraphe 
precedent. II est enfin necessaire de reflechir sur les conditions necessaires a la 
mise en oeuvre d’une methode agile. 

6J>.1 Methodes agiles et profit de risque 

La taille du projet est le premier facteur de risque de la figure 6.6. Si l’on regarde 
sa valorisation avec les metriques donnees a l’annexe C, on peut considerer 
qu’un projet agile devrait generalement se situer a un niveau has, compte tenu 
des preconisations en matiere de duree visee (moins de 18 mois) et de taille 
d’equipe (moins de dix personnes). 
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Le deuxieme facteur, la difficult^ technique, comporte differents criteres qui 
peuvent etre regroupes en trois grandes rubriques : experience technique, 
contrainte de performance et presence d’une responsabilite technique interne a 
l’entreprise. Pour la premiere, l’excellence technique fait partie des principes du 
Manifeste agile, ce qui se traduit dans les methodes par une attention a la 
progression des competences, mais aussi a la selection des developpeurs. Pour 
laseconde, certains projets peuvent inclure des exigences de performance 
elevees. Meme si elles peuvent etre discutees avec le client et si le groupe peut 
etre mobilise pour trouver des solutions efficaces, ce critere est variable selon les 
projets, et le risque ne peut etre considere a priori comme faible. 

Le troisieme facteur, le degre d’ integration, ne peut etre considere comme 
systematiquement reduit, meme s’il est pris en compte par une integration 
continue des composants livres, qui conduit a faire plus rapidement des tests 
d’interoperabilite avec les systemes devant communiquer avec le futur produit. 

Une faible valeur du quatrieme facteur de risque, la configuration organisa- 
tionnelle, peut etre consideree comme une condition a l’utilisation d’une 
methode agile. Cependant, les methodes visant a faire collaborer des decideurs 
(sessions JRP ou JAD, ateliers facilites de DSDM...) ont en principe un effet 
positif sur l’allegement des procedures de decision et l’obtention d’un consensus. 
De plus, un role correspondant a la notion de promoteur est identifie dans 
plusieurs methodes. II est done permis de penser que ce facteur de risque, dont le 
degre peut etre eleve dans certains projets, sera reduit par une application reussie 
des techniques agiles concemant les utilisateurs. 

Le risque lie au changement peut etre reduit, en ce qui conceme la plupart 
des criteres, par la participation aux iterations de developpement, si toutefois des 
relais sont mis en place pour l’ensemble des utilisateurs. Sans remplacer une 
gestion du changement, l’utilisation d’une methode agile peut etre un element 
facilitant le changement. 

Le dernier facteur, l’instabilite de l’equipe, est soumis a differents criteres, 
internes (par exemple, l’interet du projet) ou extemes (par exemple, les possibi- 
lity offertes par le marche de l’emploi). On peut toutefois relever que plusieurs 
preconisations des methodes agiles reduisent l’apparition ou les consequences 
d’un turn-over de l’equipe : une courte duree du projet, les pratiques de program- 
mation en binomes, la rotation des equipes, ainsi que le souci des conditions de 
travail de l’equipe. 

En consequence, on peut a priori considerer qu’il devrait y avoir une reduc- 
tion du risque lorsque Ton applique une methode agile. Elle est liee d’une part a 
la definition du contenu et du perimetre de ces projets, d’ autre part aux principes 
et techniques de management de la dimension humaine qui sont proposes par 
ces methodes. 
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63.2 Methodes asiles et facteurs de succes 

Prenant un autre point de vue, nous allons examiner ce que l’on peut dire du 
potentiel de reussite d’un projet mene dans un environnement agile. 

Le premier facteur de la figure 6.8, l’implication des utilisateurs, qui pese pour 
19 % dans le succes d’un projet, devrait etre verifie, dans la mesure ou les metho- 
des agiles insistent sur l’importance des relations avec les utilisateurs et 
proposent differents moyens pour favoriser leur implication (sessions, ateliers, 
prototypes...). 

Le deuxieme facteur, le soutien de la hierarchie, est moins evident et semble 
difficilement pouvoir etre garanti de la simple utilisation d’une methode agile. 

Le troisieme facteur, la definition claire des besoins, doit etre bien compris. 
En effet, si les methodes agiles ne conduisent pas a la production de dossier 
d’ analyse et de specifications, elles mettent au coeur de l’organisation preconisee 
une prise en compte a la fois precise et dynamique des exigences. On peut done 
considerer que ce facteur, d’un poids de 15, est en general verifie. 

Un raisonnement similaire s’applique pour le quatrieme facteur, un plan de 
developpement correct, qui compte pour 11 %. L’approche iterative permet 
de visualiser progressivement les differents aspects du futur produit, ce qui 
compense l’absence de formalisation de la solution et l’instabilite des specifica- 
tions. De plus, la priorisation des fonctionnalites par le client a chaque iteration, 
ainsi que l’exigence d’un delai court, sont des caracteristiques des methodes 
agiles qui peuvent conduire a qualifier la planification de realiste. 

Le cinquieme et le sixieme facteur, attentes realistes et decoupage du projet 
en petites etapes, sont tres vraisemblablement verifies si les preconisations agiles 
sont suivies, ce qui apporte une contribution respective de 10 % et 9 % au succes 
du projet. 

Les quatre facteurs suivants concement la repartition des roles et les qualites de 
l’equipe de projet. Comme une attention particuliere est portee a l’organisation 
du travail et a l’animation d’equipe, on peut retenir que ces criteres sont valides. 

II en decoule qu’un projet se deroulant selon des preconisations agile benefi- 
cierait a priori d’un potentiel de reussite de 84 %. II faut toutefois garder a 
l’esprit que l’adoption d’une methode agile suppose certaines conditions. 

63.3 Les conditions d’ utilisation d’une methode agile 

Les methodes agiles apparaissent prometteuses en ce qui conceme les chances de 
reussite du projet. Cependant, en 2006, selon une recherche du groupe Forrester 1 , 


1. Cette etude est vendue sur http://www.forrester.com. 
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seuls 17 % des entreprises nord-americaines et europeennes, utilisent une 
methode agile. Ce paradoxe apparent s’explique par les defis 1 que represente le 
passage a une methode agile, que Ton peut regrouper en plusieurs categories : 

• La culture de l’entreprise et ses methodes de management, en particulier 
les pratiques de delegation et de collaboration, ainsi que les styles de 
leadership privilegies. En ce qui concerne la motivation, la theorie des 
facteurs d’hygiene de Herzberg, brievement decrite au § 5.3.4, peut expli- 
quer des difficultes a mobiliser les developpeurs. 

• Les caracteristiques des equipes de developpement peuvent etre un obsta- 
cle au passage a des approches agile. Le travail en binome, les tests croises 
entre developpeurs ou l’integration frequente des composants developpes 
modifient profondement le quotidien d’un developpeur travaillant 
habituellement en solitaire. Par ailleurs, compte tenu des experiences 
observees, il est difficile d’affirmer que de telles approches ne demandent 
pas des competences au-dessus de la moyenne. De plus, un travail efficient 
entre developpeur et utilisateur suppose une confiance de la part du chef de 
projet, qui traditionnellement est responsable de la plupart des decisions 
sur le contenu du projet. 

• L’appui systematique sur des procedures entre en partie en conflit avec 
l’esprit d’adaptation promu par les methodes agiles. Plus precisement, 
l’approche iterative et la tolerance aux changements de specifications 
requierent une souplesse, avec laquelle sont peu familiers les acteurs des 
projets geres selon un cycle de vie qui est planifie et pilote de fagon plus 
fine. Ainsi dans XP, les iterations de livraison correspondent en general a 
des jalons fixes et dont les dates seront respectees, alors que les iterations 
de developpement peuvent fluctuer. 

• Meme si les approches agiles sont essentiellement des principes et techni- 
ques d’ organisation, elles presupposent un environnement technique 
particulier. D’une part, la decomposition du futur systeme doit pouvoir 
aller jusqu’a un niveau elementaire de developpement, sans generer un 
besoin de coordination insoutenable. Ceci est possible avec des techno- 
logies orientees objet, mais difficilement compatible avec des grands 
systemes. D’autre part, le modele iteratif suppose l’utilisation d’outils de 
developpement rapide. 

Au-dela de cette vision un peu dichotomique, on peut aussi considerer 
que cohabitent dans une meme entreprise, differentes cultures, des niveaux de 
competence varies et fluctuants, ainsi que des environnements technologiques 

1. Voir S. Nerur, R. Mahapatra et G. Mangalaraj, « Challenges of migrating to agile methodologies », 
Communication of the ACM, 48, 5, 2005. 
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divers. Se pose alors la question du choix d’une approche agile pour un projet 
particulier. 

Differents points portant sur les trois sommets du triangle projet peuvent 
ainsi etre soulignes. 

• Si les objectifs du projet sont tres incertains et le nombre de parties 
prenantes eleve, l’utilisation d’une methode agile sera vraisemblablement 
inefficace. En effet, toutes les methodes agiles considerent, d’une fagon ou 
d’une autre, que la mission du futur systeme doit etre claire au depart, 
meme si elle peut se decliner a travers des fonctionnalites prenant des 
formes diverses. Sinon, l’incertitude demeurera dans les iterations, ou bien 
les utilisateurs pourront indiquer des directions peu compatibles entre 
elles. 

• La faiblesse et l’insuffisance des ressources par rapport a l’objectif, aussi 
bien du cote de la maitrise d’ouvrage (utilisateurs pertinents) que de la 
maitrise d’oeuvre (particulierement les developpeurs), posent probleme, 
quelle que soit l’approche retenue. Cependant, dans une approche agile, le 
probleme est amplifie a cause de l’exigence de mobilisation collective et 
celle de qualite elevee, et devrait faire l’objet d’une analyse de risque prea- 
mble. 

• Le delai est le point sur lequel les methodes agiles se sont historiquement 
differenciees. Cependant, des methodes comme XP ou SCRUM conside- 
rent que la taille limite de l’equipe de developpement est de dix personnes, 
ce qui implique un perimetre limite pour le projet. Cela suppose, dans 
certains cas, une redefinition du contenu du produit a developper. D’autres 
methodes, comme Crystal, considerent toutefois une taille plus elevee. 
Nous evoquons la question de l’application des methodes agiles a des 
projets de grande taille au chapitre 18 . 

Ainsi, une analyse des caracteristiques du projet et de son environnement 
peut conduire a retenir une methode agile et permettre un changement culturel 
local. 



_ 7 _ 

Le pilotage du projet 


7.1 LE CONCEPT DE PILOTAGE 

Le concept de pilotage a ete etudie par la cybemetique, science du controle des 
systemes. Etymologiquement, la cybemetique est l’art du pilote. Nous allons en 
rappeler les principes de base. 

Un systeme est classiquement represente comme une transformation. Celle- 
ci traduit la valeur ajoutee entre un flux entrant et un flux sortant (figure 7.1). 
Un projet systeme d’information peut ainsi etre represente comme un systeme 
transformant une demande de gestion d’information en un dispositif logiciel/ 
reseau/organisation installe. 


Entrees 

I 

Transformation 

X 

Sorties 

Figure 7.1 — Schema generique d’un systeme. 

Un systeme est determine si, connaissant les valeurs des entrees, on peut 
predire les valeurs des sorties. Les projets systeme d’information ne sont pas des 
systemes determines. Meme si les actions de la transformation sont prevues et 
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planifiees (normes, regies, procedures, calendrier.), les projets ne se deroulent 
jamais exactement comme prevu. L’ indetermination peut avoir differentes 
causes : 

• l’ignorance de l’existence de certaines entrees (besoins mal identifies) ; 

• l’ignorance de certaines sorties, notamment l’effet retour de certaines 
sorties (resultats des points de validation par le maitre d’ouvrage) ; 

• l’incertitude de certaines regies de transformation (sous-estimation des 
charges) ; 

• l’ignorance des effets de l’environnement (modification de la reglementation 
en cours de deroulement de projet). 

Les aleas exigent de modifier le reglage de la transformation si Ton veut obte- 
nir les sorties desirees : c’est le role du pilotage. Pour cela, le systeme de pilotage 
a besoin de moyens lui permettant de voir et d’agir. Ce sont les variables essen- 
tielles et les variables d’action. 

• Les variables essentielles sont des sorties particulieres du systeme : ce sont 
des criteres permettant de mesurer la reussite de la mission. 

• Les variables d’action sont des entrees particulieres du systeme, qui modi- 
fient le fonctionnement prevu. Le resultat de la transformation varie 
suivant les valeurs assignees aux variables d’action (figure 7.2). 


Entrees 



Figure 7.2 — Schema de pilotage d’un systeme. 


Pour pouvoir piloter son projet, le chef de projet a besoin de variables essen- 
tielles : c’est son tableau de fiord. II lui permet de detecter le plus rapidement 
possible d’eventuels problemes et d’eviter ainsi des situations irremediables. II 
doit egalement disposer de variables d’action a actionner en fonction des resul- 
tats figurant sur son tableau de bord. Par exemple, si un membre de l’equipe de 
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projet se casse la jambe au ski, il reaffecte ses taches a d’autres personnes ou fait 
appel a des ressources supplementaires. Si des difficultes imprevues se traduisent 
par une charge de travail superieure a celle qui avait ete estimee, il faut eventuel- 
lement negocier avec le maitre d’ouvrage une modification du perimetre fonc- 
tionnel pour pouvoir respecter un delai imperatif. 

Le pilotage d’un systeme est l’ensemble des processus qui permettent de 
maitriser et de guider son fonctionnement et son evolution. Les deux concepts 
cles du pilotage sont le controle et la regulation. 

Le controle comprend : 

• la prise en compte d’objectifs, c’est-a-dire l’etablissement de variables 
essentielles (ce sont les variables du tableau de bord) et des plages admissi- 
bles pour chaque variable (identification des « zones rouges ») ; 

• la determination de moyens d’ actions pouvant faire varier les resultats 
(fixation de variables d’action). 

La regulation vise a maintenir le systeme dans les limites de fonctionnement 
que le systeme de controle a designees. C’est le suivi (examen du tableau de 
bord) et la prise en compte des ecarts (utilisation des variables d’action). 

La difficulty de pilotage d’un systeme est proportionnelle a sa variete. On 
appelle variete d’un systeme le nombre d’etats differents qu’il peut prendre. Il ne 
peut etre totalement maitrise a priori que si le systeme de pilotage possede une 
variete au moins egale, c’est-a-dire qu’il y a autant de reponses que d’etats possi- 
bles du systeme. C’est ce qu’on appelle la « loi de la variete requise ». 

Il est illusoire et couteux de chercher a priori une maitrise complete des systemes 
complexes. Plutot que de construire des dispositifs de pilotage avec une variete 
elevee, on va miser sur des systemes de pilotage pouvant s’adapter et apprendre. 

L’adaptation est la faculte de faire face a de nouvelles situations. Si un systeme 
de pilotage possede a un instant t un registre R(t) de reponses a des etats E(t) du 
systeme a controler S, il y a adaptation si S presentant un nouvel etat e(t+l), 
pour lequel R(t) ne contient pas de reponse, le systeme de pilotage est capable de 
decouvrir une reponse r(t+l) convenable. 

Un systeme de controle est adaptatif si sa gamme de reponses croit, ainsi que 
sa capacite de selection, c’est-a-dire sa variete. L’etre humain est le plus grand 
generateur de variete. 

L ’apprentissage est la faculte de memoriser et de cumuler l’adaptation. Il y a 
apprentissage si r(t+l) est memorisee dans le registre des reponses, de telle faqon 
que si e(t+l) se presente a nouveau, le systeme de controle propose la reponse 
r(t+l). Pour qu’il y ait adaptation, il faut des moyens de memorisation. 
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Le role du chef de projet est rendu necessaire par le besoin d’adaptation aux 
situations imprevues, requis tout au long du projet. II s’appuie sur un tableau de 
bord. L’apprentissage necessite un dispositif de capitalisation du savoir-faire dans 
l’entreprise. 

Nous allons presenter une proposition de structure et de contenu d’un tableau 
de bord pour le chef de projet (paragraphe 7.2 a 7.4). Une ouverture sur le pilo- 
tage necessaire en cas de sous-traitance est ensuite apportee (paragraphe 7.5). Ce 
chapitre se termine par quelques elements de base pour une capitalisation d’expe- 
rience sur les projets (paragraphe 7.6). 

7.2 LE TABLEAU DE BORD DU CHEF DE PROJET 

7.2.1 L’ object'd du tableau de bord 

Le projet est planifie et organise : le processus de production va demarrer. On a 
prealablement effectue un diagnostic sur les risques qui le menacent, ce qui 
a permis d’elaborer une strategic de projet en consequence. On a decoupe le 
projet en taches, dont on a e value la charge. On a elabore une planification des 
actions, en fonction du delai imparti, des charges, des contraintes d’enchaine- 
ment et des ressources, en utilisant notamment la methode du chemin critique et 
le diagramme de Gantt. 

La planification detaillee va servir de repere pour suivre l’avancement des 
travaux. Suivre l’avancement, pour un chef de projet, c’est pouvoir repondre a 
n’importe quelle question sur : 

• ce qui a ete produit : c’est l’avancement reel du projet ; 

• ce qui a ete consomme : ce sont les ressources utilisees ; 

• les ecarts entre le planifie et le realise ; 

• l’origine des ecarts, que ce soit une cause ayant des effets sur plusieurs 
taches, par exemple l’indisponibilite d’une machine, ou un probleme 
ponctuel lie a une tache ou a une personne ; 

• ce qu’il reste a faire. 

Pour informer la maitrise d’ouvrage et pour prendre les decisions de pilotage, 
le chef de projet a besoin de gerer un ensemble d’ informations que Ton appelle le 
systeme d’information projet ou systeme d’information de pilotage. Celui-ci comprend : 

• un tableau de bord ; 

• en general complete par un journal de bord, journal ou sont consignes au 
quotidien les evenements, incidents ou faits speciaux du projet. 
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Certaines actions de pilotage sont internes au projet, la decision en est prise 
par le chef de projet, d’autres relevent d’un comite de pilotage du projet. 

Les charges des projets systeme d’information sont principalement celles des 
ressources en personnel ou leur sont directement proportionnelles (locaux, 
equipement...). Par ailleurs, les ecarts de specification vont se traduire par des 
ecarts (a venir) sur le calendrier. Nous allons done etudier principalement le 
pilotage des delais. Nous verrons ensuite les indicateurs normalises du pilotage 
des couts. 

Le tableau de bord ne doit contenir que le minimum d’information que l’on a 
l’intention d’analyser. Une erreur frequemment rencontree consiste a collecter 
periodiquement une masse d’ informations que l’on est ensuite incapable d’analy- 
ser. II s’agit de reduire la variete du tableau de bord a la capacite d’adaptation du 
chef de pro jet. 

Le dispositif mis en place a un cout : il doit etre adapte aux caracteristiques 
du projet. 

Ainsi, le degre de formalisation doit proportionnel a la taille de l’equipe ; au-dela 
de trois ou quatre personnes, la coordination personnelle s’avere insuffisante. 

La frequence des mesures est dependante de la capacite de reaction : elle 
varie entre la semaine et le mois selon les projets. 

Le dispositif doit inclure un suivi individuel, afin de responsabiliser chacun 
des membres de l’equipe : la reussite collective passe par l’engagement individuel 
dans le projet commun. 

Le tableau de bord contient ainsi deux niveaux : 

• le suivi individuel, qui permet de detecter d’eventuelles difficultes pour un 
intervenant ou sur une tache ; 

• le suivi du projet, qui sert de base a un point d’avancement periodique avec 
le maitre d’ouvrage. 

7.2.2 Le suivi individuel 

II se base sur la liste des tdches, qui sont affectees individuellement. Le descriptif de 
chaque tache comprend un identifiant — chaque tache est reperee de fagon unique 
— et les elements ayant servi pour revaluation de sa charge (methode, unites 
d’oeuvre, poids standard, ratio. . . ). A chaque tache, on associe trois types de charge : 

• la charge initiate : e’est celle de l’estimation qui a servi a faire la planifica- 
tion detaillee. Cette valeur doit toujours etre conservee. Sa modification 
priverait l’entreprise d’une possibility d’apprentissage ; 
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• la charge affectee : c’est la personnalisation de la charge initiale en fonction 
de l’experience et de la competence de celui qui va Feffectuer. Elle peut 
etre superieure ou inferieure a la charge initiale. Cette valeur represente le 
contrat entre le chef de projet et l’acteur conceme. Elle n’est en general 
pas visible pour le maitre d’ouvrage. Elle doit etre utilisee avec precaution ; 

• la charge actualisee : en cours de deroulement du projet, mais toujours 
avant que la tache ne soit commencee, des elements nouveaux peuvent 
conduire a revoir l’estimation initiale. Par exemple, l’etude technique a 
fait apparaitre des difficultes imprevues et Ton sait maintenant que la 
charge de programmation a vraisemblablement ete sous-estimee de 20 %. 
On ne modifie pas la charge initiale, mais on negocie avec le maitre 
d’ouvrage une actualisation. La valeur de la charge actualisee est alors 
prise en compte pour une nouvelle planification. 

La base d’ alimentation du tableau de bord est le compte rendu d’activite, aussi 
appele compte rendu d’avancement, redige periodiquement, en general en fin de 
semaine, par chaque intervenant affecte au projet. Le compte rendu doit etre 
regulier. Les chiffres doivent etre le plus exacts possible, sinon tous les elements 
calcules du tableau de bord seront fausses. II comprend, par intervenant et par 
tache : 

• le temps passe T : c’est la consommation qui sera imputee au projet ; 

• le reste a faire R : c’est l’estimation par l’intervenant du temps necessaire a 
l’achevement de la tache. Ce chiffre peut etre egal, inferieur ou superieur 
a la difference (charge affectee - temps passe). 

Les taches hors projet figurent egalement sur le compte rendu d’activite 
(figure 7.3). 


Mois : 

juin 2001 - semaine 1 

Tache 

Charge 

affectee 

Temps 

passe 

Reste 
a faire 

Jean-Claude 

Realisation jeu d’essai 
du module Comptabilite 

10 

3 

6 


Maladie 


1 



Representation syndicate 


1 


Roger 

Programmation du lot 
Imputation 

8 

4 

5 


Conge 


1 



Figure 7.3 — Exemples de compte rendu d’activite. 
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Le recapitulatif mensuel permet un suivi au plus fin. On y trouve pour chaque 
tache et chaque semaine du mois : 

• le temps passe ; 

• le reste a faire ; 

• Vavancement, calcule comme une difference entre les deux demieres evalua- 
tions du reste a faire : 

avancement en fin de periode n = 

reste a faire en fin de periode (n - 1) - reste a faire en fin de periode n 

Cette definition de l’avancement est specifique des productions immateriel- 
les, ou Ton ne dispose pas d’une mesure physique permettant de mesurer objecti- 
vement la production effective. Par exemple, on peut avoir ecrit la moitie du 
nombre presume de lignes de programme sans pouvoir dire que le travail est a 
moitie fait. C’est parfois plus, parfois moins. Aussi, doit-on se baser sur la dimi- 
nution du travail restant (figure 7.4). 


Depart 


Reste a faire (n) 

J 


Reste a faire (n + 1) 


Arrivee 


Avancement 


Figure 7.4 — La mesure de I’avancement. 


Cette definition implique que l’avancement pourra etre superieur, inferieur 
ou egal au temps passe. 

Un exemple de recapitulatif est donne a la figure 7.5 pour deux taches A et B 
dont la charge affectee est respectivement de 12 et 10 jours. Dans la partie droite 
du tableau, on a effectue le total du mois. L’attention du chef de projet est attiree 
quand l’avancement est inferieur au temps passe. 


Mai 2001 

Tache 

Semaine 1 

Semaine 2 

Semaine 3 

Semaine 4 

Total mois 



T 

R 

A 

T 

R 

A 

T 

R 

A 

T 

R 

A 

T 

R 

A 

Jean-Claude 

A (12 J) 

4 

8 

4 

5 

3 

5 

1 

0 

3 




10 

0 

12 


B (10 J) 







3 

7 

3 

5 

2 

5 

8 

2 

8 















18 


20 


Figure 7.5 — Exemple de recapitulatif mensuel. 
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Le bilan individuel mensuel donne pour chaque intervenant une photographic 
de sa performance. 

La partie gauche du tableau de la figure 7.6 donne les chiffres cles du mois n, 
par tache et pour le total des taches du mois. On y trouve : 

• la charge affectee ; 

• le reste a faire a la fin du mois precedent (R n _i) ; 

• le temps passe (T n ) ; 

• le reste a faire a la fin du mois n (R n ) ; 

• l’avancement du mois n : A n = R n _ j - R n ; 

• le coefficient d’utilisation de la ressource pendant le mois n : 

T n 

Nombre de jours ouvrables du mois 
qui auraient du. etre consacres au projet 

Ce ratio mesure la part du temps de l’intervenant consacree au projet. II 
est a comparer avec la disponibilite escomptee de la ressource quand on a 
elabore le planning a l’aide du diagramme de Gantt. 

• la vitesse du mois n est : 

A n 

T n 

Ce ratio compare l’avancement et le temps passe. II represente la vitesse 
d’avancement de l’intervenant. Inferieur a 1 , il doit attirer l’attention. 

La partie droite donne un recapitulatif depuis le debut du projet. Elle comprend : 

• le temps total passe, soit pour une tache donnee si elle est a cheval sur 
deux mois, ou toutes taches confondues. C’est la somme de tous les temps 
consommes ; 

• le coefficient d’utilisation : c’est le ratio entre le temps passe par I’interve- 
nant et le nombre de jours ouvrables, calcule a partir de la date de son am- 
vee sur le projet. II est analogue a celui du mois ecoule, mais porte sur 
toute la duree de presence ; 

• la performance : ce ratio mesure le degre d’atteinte des objectifs. II n’a de 
sens que pour la totalite des taches en cours ou achevees. On n’y inclut pas 
les taches non encore ouvertes. II compare la charge affectee avec la 
charge qui a ete ou qui sera vraisemblablement consommee : 

Charge affectee x 1 00 


Temps total passe + Reste a faire 
des taches ouvertes 
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Mois 3 
(20 J) 








Recapitulatif depuis 
le debut du projet 

Roger 

Charge 

affectee 

R(2) 

T(3) 

R(3) 

A(3) 

Coef. 

utilisation 

Vitesse 

Temps 

total 

Coef. 

utilisation 

Perfor- 

mance 

Tache 

A 

14 

0 









Tache 

B 

21 

18 

14 

0 

18 


1,29 

24 


88% 

Tache 

C 

15 

15 

2 

14 

1 


0,50 




Total 

50 


16 


19 

0,8 

0,75 

51 

81% 

77% 


Figure 7.6 — Exemple de bilan individuel. 


7.2.3 Le sum du projet 

Le chef de projet a besoin d’avoir periodiquement une vue de synthese de l’etat 
du projet. C’est sur cette synthese que le maitre d’ oeuvre, responsable contrac- 
tuel du projet, fera le point avec le maitre d’ouvrage. 

C’est ce qu’on appelle le tableau d’avancement du projet. En general, la maille 
est plus large que pour le suivi individuel : on ne raisonne plus sur des taches, 
mais sur des lots de taches (figure 7.7). Un lot est un regroupement de taches 
donnant lieu a des livrables qui forment un ensemble coherent. Un lot corres- 
pond a une ou plusieurs fonctionnalites et peut faire l’objet d’une recette. Les 
engagements contractuels de livraison portent le plus souvent sur des lots. Un 
exemple de repartition en lots est donne au chapitre 10 (paragraphe 10.1.3). 



Mois 

n-1 

Mois 

n 

Recapitulatif 
depuis le debut du projet 

Lots 

T 

R 

T 

R 

A 

Evolution 
charge restante 

Charge 

initiale 

Temps 
total passe 

Evolution 
globale 
charge % 

Avancement 
























Figure 7.7 — Structure du tableau d’avancement du projet. 
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Ce tableau, alimente par les recapitulates mensuels, comprend trois parties : 

1. Rappel des elements du mois n - 1 : pour toutes les taches, meme non 
commencees en fin de moins n - 1, on trouve le temps passe (T) et le reste 
a faire (R). 

2. Les elements du mois n : pour toutes les taches, meme non commencees, 
on a le temps passe (T), le reste a faire (R) et l’avancement (A). 

Cela permet de calculer la tendance du passe recent entre le mois n-1 et le 
mois n : 

Evolution de la charge restante = T(n) — A (n) 

= T(n) - (R(n- 1) - R(n)) 

= (T(n)+R(n))-R(n-l) 

Ce parametre indique si durant le mois la charge restante du projet 
augmente ou non. Si sa valeur est negative, la charge s’allege, si elle est 
positive la charge s’alourdit. 

3. Les elements recapitulates depuis le debut du projet : la charge initiale est 
la somme de toutes les charges initiales, eventuellement actualisees ; le 
temps total passe represente le temps de travail affecte au projet depuis 
le demarrage. 

Cela permet de faire une comparaison globale entre la charge estimee et la 
charge consommee : 

Evolution globale de la charge = 

Temps total passe + R (n) - Charge initiale 

Cet indicateur compare la charge du projet avec l’avancement. S’il est 
positif, cela signifie qu’avec les elements connus au jour du calcul, on 
prevoit deja de depasser la charge prevue. 

On calcule enfin deux ratios, le pourcentage d’ evolution qui donne le pourcen- 
tage de l’avance ou du depassement par rapport a la charge initiale : 

Evolution globale de la charge x 100 
Charge initiale 

et le pourcentage d’avancement qui compare l’avancement a la fin du mois n avec 
la charge initiale : 


Charge initiale - R (n) x 100 


Charge initiale 
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7.3 LE SUIVI ECONOMIQUE : LA METHODE DE LA VALEUR ACQUISE 

La methode de la valeur acquise ( Earned Value Method) permet de mesurer les 
performances du projet a une date t et d’effectuer des previsions. Elle s’appuie sur 
trois indicateurs normalises (calcules par la plupart des logiciels de suivi de projet) : 

• Valeur planifiee (VP) 1 : c’est le cout du travail planifie, base sur l’estimation 
des charges et le cout prevu des ressources. C’est qu’on a planifie de faire 
jusqu’a la date t. La VP jusqu’a la fin prevue du projet correspond au 
budget du projet et s’appelle le Budget a I’achevement (BAA) 2 . 

• Cout reel (CR) 3 : ce sont les depenses provenant du temps consomme. 
C’est le cumul de ce que Ton a effectivement depense jusqu’a la date t. 

• Valeur acquise (VA) 4 : cet indicateur est base sur l’avancement reel du 
projet et represente done ce que Ton aurait du depenser pour le travail 
effectivement realise jusqu’a la date t. 

Ces trois indicateurs peuvent etre calcules pour une activite, un ensemble 
d’activites ou l’ensemble du projet. Ils sont cumulatifs, e’est-a-dire que c’est 
toujours la valeur cumulee depuis le debut du projet jusqu’a la date t fixee. 

On en deduit deux indicateurs complementaires : l’ecart de cout et l’ecart de 
delai. 

• E cart de cout (EC) 5 = VA - CR. S’il est negatif, on depense plus que prevu ; 
s’il est positif, on sous-consomme, et s’il est nul, la productivite reelle 
correspond exactement a la productivite planifiee. 

• Heart de delai (ED) 6 = VA - VP. S’il est negatif, on avance moins vite que 
ce que Ton avait planifie ; s’il est positif, on a pris de l’avance, et s’il est 
nul, le travail ce realise conformement a ce qui avait ete planifie. 

La figure 7.8 donne une illustration. En abscisse, on a represente l’axe du 
temps et en ordonnee les couts cumules. On suppose que Ton se situe au jour 10, 
date a laquelle on va calculer la performance. 

Le budget total du projet est de 150 K€. 

La VP au jour 10 est de 80 K€. C’est ce que Ton a prevu de faire et de depenser, 
par exemple 8 jours de travail pour l’ensemble de l’equipe de projet a 10 K€ par jour. 


1. En anglais : Planned value (PV). Anciennement appele : CBTP (BCWS en anglais). 

2. En anglais : Budget at completion (BAC). 

3. En anglais : Actual cost (AC). Anciennement appele : CRTE (ACWP en anglais). 

4. En anglais : Earned value (EV). Anciennement appele : CBTE (BCWP en anglais). 

5. En anglais : Cost Variance (CV). 

6. En anglais : Schedule Variance (SV). 


7. Le pilotase du projet 


Le CR est de 95 K€. On a done depense plus que ce que Ton avait planifie. 
Mais peut-etre a-t-on avance davantage que prevu ? La VA va nous permettre de 
le savoir. Elle est de 70 K€, e’est-a-dire que, compte tenu de l’avancement reel, 
on aurait du depenser uniquement 70 K€. 

L’ecart de cout est de : 70 K€ - 95 K€ = - 25 K€. 

L’ecart de planning est de : 70 K€ - 80 K€ = - 10 K€. 

Le projet, au jour 10, est done en retard et en surconsommation. 



On peut traduire les ecarts sous forme d’indicateurs de performance : 

• Indice de performance des couts (IPC) 1 = VA/CR 

• Indice de performance des delais (IPD) 2 = VA/VP 

On calcule parfois un indicateur qui lisse les variations de performance et qui 
est souvent considere comme stable, e’est-a-dire variant au maximum de 10 %, 
lorsque Ton a depasse 20 % d’achevement du projet : 

• Indice de performance des couts cumule (IPCC) = 

Somme VA (calculees a chaque fin de periode/Somme CR (calcules a 
chaque fin de periode). 

On peut alors faire une prevision des couts a l’achevement du projet : 

• Prevision a V achievement (PAA) 3 : e’est l’estimation du cout total du projet, 
compte tenu des performances jusqu’a ce jour et des risques previsibles. 


1. En anglais : Cost performance index (CPI). 

2. En anglais : Schedule performance index (SPI). 

3. En anglais : Estimate at completion (EAC). 
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Pour calculer la PAA, on distingue trois cas de figure. 

• 1 . On considere que les ecarts sont accidentels et on n’en tient pas compte 
pour le futur. Alors : PAA = Couts reels a ce jour + Travail restant 
= CR + (Budget a P achievement - Valeur acquise). 

• 2. On considere que les ecarts sont representatifs du futur et on fait une 
projection. Alors : PAA = Couts reels a ce jour + (Travail restant/indice 
de performance des couts) = CR + (BAA - VA)/IPC. 

On peut aussi utiliser HPC C . 

• 3. On considere que les conditions ont change, et l’on fait une nouvelle 
estimation. Alors : PAA = Couts reels a ce jour + Cout estime a 1’ achieve- 
ment 1 = CR + CEA. 

On peut enfin calculer l’ecart previsible en fin de projet : 

• Ecart a I’achevement (EAC) 2 

EAC = Budget a F achievement - Prevision a l’achevement = BAA - PAA. 

Eventuellement, on calcule l’indice de performance necessaire pour terminer 
le projet dans le budget : 

• Indice de performance requis (IPR) 3 : 

IPR = Travail restant/Budget restant = (BAA - VA)/(BAA - CR). 

L’utilisation de l’ensemble de ces indicateurs est proposee au chapitre 12 
(paragraphe 12.15). 


7-4 LES DECISIONS DE PILOTAGE 

De nombreuses decisions sont prises en cours de projet, suite a l’analyse de 
l’avancement et des performances, et a divers imprevus. Le processus de decision 
ne s’appuie pas sur des techniques generiques. Nous allons toutefois presenter 
deux techniques generates qui peuvent etre utilisees dans des contextes decision- 
nels : l’arbre de decision, accompagne de la technique de la valeur monetaire 
attendue, et le calcul de rentabilite selon le ROI. 


1. En anglais : Estimate to complete (ETC). 

2. En anglais : Variance at completion (VAC). 

3. En anglais : To complete performance index (TCPI). 
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7.4.1 L’arbre de decision et la valeur monetaire attendue (VMA) 

Un arbre de decision est une structure arborescente qui permet de representer 
des alternatives a plusieurs niveaux. On a ainsi differents chemins, que l’on 
souhaite comparer. Pour cela, on va attacher des gains et pertes possibles pour 
chaque alternative. La technique de la Valeur monetaire attendue permet de 
calculer la valeur des differents scenarios selon les decisions prises. Nous avons le 
schema de la figure 7.9 : 


Scenario A 
Cout attache C A 


Resultat 1 

Probabilite d’ occurrence : pi 
Montant du gain ou de la perte : Ml 


Resultat 2 

Probabilite d’ occurrence : p2 
Montant du gain ou de la perte : M2 


Figure 7.9 — Schema de la methode de la valeur acquise 


La valeur du scenario est egale a : X (probabilite *gain/perte) - Cout attache 
au scenario. 

La decision, sous Tangle financier, va privilegier le scenario ayant la valeur la 
plus elevee. 



Figure 7.1 0 — Exemple d’application de la methode de la valeur acquise 
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Soit par exemple un progiciel de paie que Ton doit faire evoluer pour prendre 
en compte une nouvelle reglementation. II s’agit de choisir entre faire une 
evolution en profondeur avec ajout de nouvelles fonctionnalites, qui devrait 
permettre de gagner de nouveaux clients, et faire une evolution minimum. On a 
fait des estimations du cout de chacune des options, et on a fait des hypotheses 
sur la demande des entreprises (figure 7.10). Le calcul montre que le scenario 
« Evolution maxi » est a privilegier. 

7.4.2 Le calcul de rentabilite : le ROI 

Le calcul du ROI ( Return on Investment) est une technique classique pour 
evaluer la rentabilite d’un investissement, compte tenu de son cout, de sa duree 
de vie et des gains attendus. Pour pouvoir l’utiliser, il faut au depart disposer de 
trois elements d’information : 

1. Une estimation de la duree de vie de 1’ investissement. 

2. Des previsions de depenses, periode par periode. La periode est souvent 
annuelle, et les depenses sont aussi bien l’investissement que les couts de 
fonctionnement a venir. 

3. Des previsions de recettes, qui peuvent etre des diminutions de depenses, 
pendant toute la duree de vie de l’investissement, periode par periode. 

On commence par etablir un tableau des flux de tresorerie, periode par 
periode, que l’on appelle chronique du cash-flow. Pour chaque annee, le cash-flow 
= Recettes - Depenses. Un exemple est donne dans le tableau de la figure 7.11. 


Annee 

2007 

2008 

2009 

2010 

2011 

2012 

Depenses 

50 

60 

70 

10 

10 

20 

Recettes 

0 

0 

0 

60 

100 

200 

Cash-flow 

(recettes-depenses) 

-50 

-60 

-70 

50 

90 

180 


Figure 7.1 1 — Exemple de chronique de cash-flow 


On souhaite resumer cette chronique par un seul chifffe pour pouvoir comparer 
des projets d’investissement. On va le faire par trois variables : le delai de 
remboursement, la valeur actuelle nette et le taux de rendement interne. 

Le delai de remboursement est delai au bout duquel les recettes cumulees depas- 
sent les depenses cumulees. Sur notre exemple, le delai est de 5 ans (figure 7.12). 
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Annee 

2007 

2008 

2009 

2010 

2011 

2012 

Depenses 

50 

60 

70 

10 

10 

20 

Recettes 

0 

0 

0 

60 

100 

200 

Cash-flow 

-50 

-60 

-70 

50 

90 

180 

Cash-flow cumule 

-50 

-110 

-180 

-130 

-40 

140 


Figure 7.12 — Exemple de calcul de delai de remboursement 


Pour calculer la valeur actuelle nette (VAN), il faut faire une hypothese sur le 
taux de placement de l’argent, que Ton appelle taux d’actualisation (t act ). On 
actualise la chronique de cash-flow en ramenant chaque somme future M 
(acquise ou depensee periode n) a son equivalent actuellement. La somme 
actualisee M act est celle que Ton devrait avoir pour obtenir M a la periode n en 
la plagant au taux t act . 

M act = M/(l+ t act ) n . 

La valeur actuelle nette de l’investissement est la somme des cash-flows 
actualises jusqu’a la fin de la duree de vie de l’investissement. Dans notre exemple, 
avec un taux d’actualisation de 6 %, la VAN est de 74 (figure 7.13) 


Annee 

2007 

2008 

2009 

2010 

2011 

2012 

Depenses 

50 

60 

70 

10 

10 

20 

Recettes 

0 

0 

0 

60 

100 

200 

Cash-flow 

-50 

-60 

-70 

50 

90 

180 

Cash-flow actualise 

(6%) 

-47 

-53 

-59 

40 

67 

127 

Cash-flow actualise 
cumule 

-47 

-101 

-159 

-120 

-52 

74 


Figure 7.13 — Exemple de calcul de valeur actuelle nette 


Le taux de rendement interne (TRI) est le taux d’actualisation qui rend la VAN 
nulle a la fin de la duree de vie de l’investissement. Cette variable est equiva- 
lente a la VAN, mais peut etre plus parlante. Sur notre exemple, le TRI est de 
19 % (figure 7.14). 

Des exercices d’ application de la VMA et du ROI sont proposes au chapitre 12. 
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Annee 

2007 

2008 

2009 

2010 

2011 

2012 

Depenses 

50 

60 

70 

10 

10 

20 

Recettes 

0 

0 

0 

60 

100 

200 

Cash-flow 

-50 

-60 

-70 

50 

90 

180 

Cash-flow actualise 

(19 %) 

-42 

-42 

-42 

25 

38 

63 

Cash-flow actualise 
cumule 

-42 

-84 

-126 

-101 

-63 

0 


Figure 7.14 — Exemple de calcul du taux de rendement interne 


7.5 LE PILOTAGE D UN PROJET SOUS-TRAITE 

7 - 5.1 La sous-traitance d’un projet 

On peut sous-traiter tout ou partie d’un projet (etude, realisation, formation...) 
a une entreprise tierce, ce qui donne lieu a un contrat. II y a trois grandes formes 
de sous-traitance. 

1. La sous-traitance au forfait consiste a faire realiser des travaux pour un 
montant forfaitaire. Le client attend du foumisseur un engagement de 
resultat. 

2. La sous-traitance en regie consiste a acheter pour une duree definie une 
mise a disposition de personnel appartenant a une entreprise tiers. II s’agit 
de la part du fournisseur d’un engagement de moyens. 

3. La sous-traitance d’expertise consiste a acheter une competence dans un 
domaine pour traiter un probleme precis (estimation de charge, planifi- 
cation). Le foumisseur intervient ponctuellement ; son intervention se 
termine par des recommandations. 

Dans les deux demiers cas, le chef de projet beneficie de ressources supplemen- 
taires. Son role de pilote n’en est pas affecte. En revanche, dans le premier cas, 
une partie de la responsabilite de conduite de projet est transferee au sous-traitant. 

Le choix d’un sous-traitant prend generalement en compte des criteres divers, 
auxquels on peut accorder des poids differents. Ils peuvent etre d’ordre technique 
(approche technique proposee, competences techniques...), commercial (prix, 
clause de propriete...), institutionnel (taille et type d’entreprise, capacite finan- 
ciere...) ou managerial (procedures, methodes, systeme qualite...). On les 


7. Le pilotase du projet 


0 


presente parfois dans une grilk multicritere assortie d’un systeme de ponderation. 
Un exemple de notation de trois fournisseurs par une telle grille est donne a la 
figure 7.15. 


Critere 

Poids 

Fournisseur A 

Fournisseur B 

Fournisseur C 

Technique 

3 

3 

9 

7 

21 

5 

15 

Commercial 

2 

4 

8 

5 

32 

5 

10 

Methode 

1 

1 

1 

3 

3 

3 

3 

Gestion projet 

3 

1 

3 

3 

9 

1 

3 

Note 



21 


65 


31 


Figure 7.15 — Exemple d’utilisation d’une grille multicritere 


7 ~ 5.2 Le role du chef de projet en cas de sous-traitance 

La premiere responsabilite du chef de projet est d’etablir un cahier des charges 
indiquant les resultats attendus, accompagnes d’eventuelles contraintes (format 
de remise des livrables, securite, volumetrie, portability...) et exigences (docu- 
ments de suivi de projet...). Le cahier des charges fait parfois l’objet d’un dialo- 
gue et d’un accord entre les deux parties. 

La redaction du cahier des charges suppose que le chef de projet a effectue un 
decoupage structurel, voire un decoupage temporel si une partie seulement du 
projet est sous-traitee. 

II est fortement conseille d’effectuer une analyse de risques, car l’extemalisa- 
tion des risques ne les diminue pas — sauf eventuellement sur le facteur Instabi- 
lity de l’equipe de projet — et les chances de succes peuvent etre compromises, 
sans que Ton ne puisse plus rien faire. 

II serait dangereux de ne faire aucune evaluation des charges, comme cela a 
ete evoque au paragraphe 3.2. II est en effet difficile de selectionner un fournis- 
seur, parmi des offres qui comportent des prix tres eloignes. II importe done de 
faire une estimation globale, soit par la methode Delphi, soit par la methode des 
points fonctionnels, soit par analogie avec un projet comparable. 

La planification du projet releve de la responsabilite du sous-traitant. Cepen- 
dant, le chef de projet qui sous-traite doit avoir une visibility sur le jalonnement 
du projet : pour cela, il est conseille de privilegier la remise de livrables interme- 
diaires, ce qui favorise le suivi des etapes du projet. 
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Le pilotage d’un projet sous-traite s’exerce a deux niveaux. Un premier 
niveau est de la responsabilite exclusive du sous-traitant. Un second niveau est 
partage par le chef de projet et le sous-traitant. Lors de la passation du contrat, 
un format de tableau de bord doit etre defini, par exemple analogue a celui de la 
figure 7.7. Des reunions de suivi regulieres et frequentes doivent etre tenues et 
faire l’objet d’un engagement contractuel entre les deux parties. II est preferable 
d’ avoir une reunion d’une heure chaque semaine, plutot que de trois heures tous 
les mois. Cette proximite permet d’anticiper, ou du moins de decouvrir suffisam- 
ment tot certaines difficultes pour pouvoir eventuellement prendre des decisions 
d’orientation. De plus, le chef de projet doit pouvoir a son tour informer son 
maitre d’ouvrage sur l’avancement du projet, done en avoir une connaissance 
precise et a jour. 

Ainsi, la charge la plus importante pour le chef de projet qui sous-traite, 
concerne le pilotage conjoint avec le sous-traitant. 


7.6 LE MANAGEMENT DES CONNAISSANCES POUR LES PROJETS 

7.6.1 La capitalisation d’ experience sur les projets 

Nous allons clore ce chapitre sur le pilotage en situant un projet particulier dans 
le contexte plus large de l’entreprise. On peut considerer que la responsabilite 
d’un chef de projet s’etend a la capitalisation de la nouvelle experience qu’il 
vient d’acquerir. En effet, la memorisation des elements de synthese d’un projet 
permet l’apprentissage collectif. Nous allons en donner quelques elements. 

La memoire sur un projet comporte d’abord un bilan de projet, avec les princi- 
pals caracteristiques du projet : 

• nom du pro jet ; 

• date de debut, date de fin ; 

• nombre total d’intervenants ; 

• domaine d’application. 

Le bilan des ressources utilisees peut etre presente comme dans le tableau de 
la figure 7.16 qui s’appuie sur la typologie utilisee pour l’evaluation des charges. 

II s’agit ensuite de suivre les bases de valorisation standard. Par exemple, pour 
le suivi de ratios, on elabore le tableau de la figure 7. 1 7 et pour le suivi des unites 
d’oeuvre celui de la figure 7.18. 
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Type 
de tache 

Nombre 

Charge 

initiale 

Charge 

constatee 

Nombre 
jours ecart 

% ecart par rapport 
a la charge initiale 

Type 1 






Type 2 






Total 







Figure 7.16 — Tableau de bilan de projet. 


Type de tache 

Charge 

initiale 

Charge 

constatee 

Ratio 

applique 

Ratio 

constate 

Programmation 

85 

100 

- 

- 

Jeu d’essai 

17 

18 

20% 

18% 


Figure 7.1 7 — Tableau de suivi des ratios. 


Type 
de tache 

Poidsde 

l’unite 

d’ceuvre 

Nombre 

d’unites 

d’oeuvre 

Charge 

moyenne 

constatee 

Ecart 

Ecart-type 

(avec Cj = charges reelles) 

Type 

P 

N 

m 

p - m 

1/n [Sommej_| ^ n (Cj - m) 2 ] 1/2 


Figure 7.18 — Tableau de suivi des unites d'oeuvre. 


7.6.2 Le knowledge management applique aux projets systeme 
d'information 

La capitalisation de l’experience acquise sur les projets s’inscrit aujourd’hui dans 
une perspective plus vaste qu’il y a quelques annees, cedes du « knowledge 
management », c’est-a-dire du management des connaissances. On en attend un 
meilleur partage entre les chefs de projets des bonnes pratiques et des erreurs a 
eviter, pour une maTtrise accrue des projets. Celle-ci se traduit par des ameliora- 
tions tangibles — on peut en voir les effets — ou non, et mesurables — on peut 
definir une metrique — ou non. On peut en donner quelques exemples. 

• L’ augmentation du respect des delais dans les projets est un gain tangible 
et mesurable. 

• L’ amelioration de la qualite des dossiers est un gain tangible, mais diffici- 
lement mesurable. 

• La satisfaction des utilisateurs, evaluee par des enquetes de satisfaction, est 
mesurable, mais pas toujours tangible. 

• La qualite de la communication entre les chefs de projet n’est ni mesurable, 
ni tangible a court terme. 
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Le knowledge management participe d’une nouvelle approche des organisa- 
tions orientee vers le mode de travail en reseau et la mise en commun des infor- 
mations. Pour cela, il s’agit de construire une memoire organisationnelle qui 
pourra etre utilisee par tous ceux qui en ont besoin. On peut distinguer plusieurs 
categories de memoire : 

• la memoire individuelle : les connaissances, experiences et savoir-faire des 
chefs de projet ou des autres participants aux projets ; 

• la memoire du projet : le dossier de projet contenant les caracteristiques du 
projet, son deroulement, son bilan ; 

• la memoire de l’entreprise : les normes, methodes et parametres retenus 
dans l’entreprise ; 

• la memoire de la profession : l’etat de Part formalise, les methodes diffu- 
sees... 


Differents obstacles freinent la capitalisation. Souvent, il n’y a pas responsa- 
ble de la capitalisation ; or, l’analyse de ce qu’il faut retirer du projet est parfois 
difficile. En fin de projet, le chef de projet est rarement disponible pour des 
taches additionnelles ; de plus, il n’a pas envie d’exposer des ecarts negatifs de 
charge ou delai. S’il n’y a pas de structure de stockage, l’experience reste expri- 
mee dans des documents heterogenes C’est pourquoi la capitalisation necessite 
un dispositif qui comprend un contenu, une organisation, des procedures et des 
technologies. 

Contenu 

Il s’agit de definir ce sur quoi on veut capitaliser. Le contenu couvre les differen- 
tes facettes de la gestion de projet et comprend notamment : des decoupages 
structurels ; des plans types ; des organisations types ; des fiches contenant les 
bonnes pratiques ; des fiches techniques... 

Ce contenu doit etre structure en themes et en elements de connaissance. 
Par exemple, la methode REX (Re tour d’Experience) utilisee dans le domaine 
industriel et commercialisee avec un outil par la societe Euriware, repose sur 
l’architecture (simplifiee) suivante : 

• un referentiel terminologique identifiant les elements- types sur lesquels 
on souhaite capitaliser (equipement, defaillance, tache...) ; 

• des elements de connaissance associes a un ou plusieurs termes du referen- 
tiel terminologique ; 

• une structure de description de chaque element de connaissance, pouvant 
etre de differentes natures (documentation, formalisation d’une expe- 
rience, savoir-faire acquis lors de la realisation d’une tache...). 
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De fagon generale, pour que les resultats d’experience puissent etre partages, 
il est conseille de respecter les regies suivantes : 

• la connaissance doit etre decoupee en elements manipulables ; 

• les elements doivent etre references de fagon claire ; 

• les elements doivent etre cibles sur un probleme precis (analyser les 
risques, evaluer une charge, rediger un dossier d’analyse...) ; 

• les elements doivent etre organises avec differents niveaux de detail. 

Organisation 

II s’agit de preciser les roles et les responsabilites. Certains auteurs ont etudie les 
facteurs qui influent sur la performance d’une entreprise. II en ressort que la 
performance individuelle n’intervient qu’en sixieme position, alors que le support 
que peut apporter l’organisation aux individus vient en second rang (le premier 
etant la definition claire des produits ou services offerts). Cela signifie que [’orga- 
nisation mise en place en vue de capitaliser est essentielle. On distingue souvent 
les roles suivants : 

L’expert est porteur de connaissances. C’est un chef de projet, plus ou moins 
experimente. 

Le knowledge manager, gestionnaire de connaissances, responsable du proces- 
sus de creation et devolution de la connaissance partagee. Dans le contexte 
informatique, ce peut etre le responsable qualite a qui on confie la definition des 
procedures de capitalisation. 

Le responsable de theme est responsable du contenu de son domaine, par exem- 
ple dans le cas d’un intranet il est en charge de la connaissance nouvelle qui doit 
apparaitre dans l’espace collectif. Il analyse les bilans de projets, est a l’affut de 
nouvelles connaissances de la profession, fait evoluer certains parametres (poids 
des unites d’oeuvre...). Son role comporte une dimension relationnelle, toute 
nouvelle connaissance devant etre expliquee aux experts et validee avec eux. Il 
est egalement responsable de la redaction des pages et de la validite des informa- 
tions. Si la connaissance est de taille reduite, le responsable de theme est respon- 
sable de l’ensemble du contenu de tous les themes. 

Cette organisation repose sur la distinction de quatre formes de connaissances 
(figure 7.19), selon deux criteres : elle est individuelle ou collective ; elle est expli- 
cite — le detenteur en est conscient — ou tacite — le detenteur utilise la connais- 
sance sans en etre conscient, de fagon implicite ou automatique 1 . 

1. Nonaka I., A dynamic theory of organizational knowledge creation, Organization Science, 5, 1, 

fev. 1994, pp. 14-37. 
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Le passage du collectif a l’individuel correspond a un processus d’appropria- 
tion ou d’apprentissage. 

Le passage de l’individuel au collectif correspond a un enrichissement des 
connaissances et/ou des pratiques collectives. 

Le passage du tacite a l’explicite correspond a de l’explicitation et/ou de la 
formalisation. 

Le passage de l’explicite au tacite correspond a l’assimilation. 

La capitalisation d’experience sur les projets systeme d’information signifie 
dune part un passage des connaissances individuelles explicites vers des connais- 
sances collectives, d’autre part une explicitation de certaines connaissances tad- 
tes, en general individuelles. Pour passer au stade du knowledge management, il 
faut ensuite organiser les processus d’apprentissage et d’appropriation. 



Individuelle 

Collective 

Explicite 

Connaissance dont le detenteur est 
conscient 

Par exemple : ma fa§on de calculer 
les charges pour un projet group- 
ware dans un environnement Notes/ 
Domino 5. 

Connaissances accessibles a tous 
Par exemple : l’etat de Part de 
1’ estimation des charges. 

Tacite 

Connaissance pratique que le deten- 
teur utilise sans qu’elle fasse l’objet 
d’une « regie » 

Par exemple : pour certains projets 
que je ne « sens » pas bien, je 
rajoute automatiquement 10 % de 
charge. 

Connaissances partagees sans que 
les personnes en soient conscientes 
Par exemple : un projet se mene de 
fagon « top-down ». 


Figure 7.19 — Formes de connaissance. 


Procedures 

II s’agit de definir comment capitaliser et comment reutiliser la connaissance. La 
logique du management des connaissances doit prendre en compte a la fois le 
producteur et le consommateur d’informations. Ceci est d’autant plus vrai dans 
le cas des projets informatiques, car ces deux populations se recouvrent large- 
ment. Les procedures doivent done : 

• proposer au producteur des procedures simples de capitalisation de ses projets ; 

• definir des procedures claires devolution et d’enrichissement des connais- 
sances collectives ; 
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• foumir au consommateur des informations pertinentes, c’est-a-dire ciblees 
sur les problemes rencontres ; 

• donner au consommateur des moyens d’acceder facilement et rapidement 
a l’information necessaire. 

Les procedures doivent prendre en compte le fait que les differents modes de 
communication foumissent une information de qualite differente, comme indi- 
que dans le tableau de la figure 7.20. 


Mode de communication 

Qualite de l’information 

Echange en face a face 

Tres riche 

Echange a distance (telephone, mail) 

Riche 

Reunion 

Riche si la reunion est hien conduite 
(ordre du jour et choix des participants) 

Ecrit (document, dossier. . .) 

Moyenne 


Figure 7.20 — Modes de communication et qualite de I’information. 


Technologies 

Tout dispositif de management des connaissances doit s’appuyer sur des outils 
qui allegent les contraintes bees aux processus d’ alimentation, qui facilitent 
l’exploration et qui permettent un stockage d’informations devant continuelle- 
ment etre enrichies et actualisees. Trois types d’outils complementaires peuvent 
etre utilises : 

• des outils d’infrastructure et de diffusion (messagerie, intranet...) ; 

• des outils de memorisation pour structurer et Stocker la connaissance 
(AGL, bases de donnees, gestion electronique de document...) ; 

• des outils d’exploitation de la connaissance (moteur de recherche, outils 
d’analyse...). 


7.7 LE PILOTAGE D UN PROJET EN MODE AGILE 

7.7.7 Le suivi d’un projet agile 


La formalisation du suivi n’est pas un aspect preconise par les methodes agiles. II 
ne faudrait pas en conclure que le suivi est neglige, bien au contraire. 
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Le suivi individuel est assure de fagon etroite, notamment lors des iterations 
de developpement, par le principe des breves reunions quotidiennes, preconisees 
notamment par XP et SCRUM, qui permettent de faire un point sur la progres- 
sion. Certains roles favorisent une proximite avec l’equipe, comme le tracker 
dans XP, le scrum master ou le chef d’equipe dans DSDM. 

Selon le Manifeste Agile, l’indicateur d’avancement le plus pertinent est la 
mise a disposition de logiciel qui marche. Cette position se justifie dans 
lamesure ou la structure de decoupage du projet a permis d’identifier, a une 
maille fine, des composants pouvant etre testes de fagon independante. Certains 
tableaux simples, comme le bumdown chart de SCRUM qui visualise la diminu- 
tion du reste a faire, assurent une certaine formalisation de l’avancement. 

En ce qui conceme le suivi du projet vis-a-vis du client, on peut relever que 
les engagements vis-a-vis des jalons que represented les fins de cycle de livrai- 
son ont un caractere imperatif, comme enonce par la timebox (cf. § 4.8). En 
revanche, le calendrier des iterations de developpement est reajuste en fonc- 
tion du deroulement reel, ce qui limite une communication formelle a ce 
niveau-la. Le responsable du projet a done un role accru vis-a-vis de la maitrise 
d’ouvrage, puisqu’il ne peut pas compter sur la mediation d’un tableau de bord 
bien formalise. 

7 . 7.2 Les variables d’action pour un projet agile 

Les aleas ne sont pas consideres comme des evenements negatifs, mais comme 
partie integrante du deroulement des projets. En particulier, les changements de 
specifications et les difficultes rencontrees par les developpeurs sont pris en 
compte dans le pilotage du projet. 

On peut ainsi mentionner les variables d’action suivantes : 

• La reduction du perimetre fonctionnel, si le champ determine au debut 
d’une iteration rend impossible le respect de la timebox. 

• Le renvoi dans une iteration de livraison ou une livraison ulterieure. 

• La tenue d’un « conclave », defini comme une session extraordinaire qui 
conduit a des decisions importantes n’ayant pu etre prises lors des sessions 
normales. Ces decisions portent en general sur des options de conception 
qui bloquent l’avancement du projet car elles demandent un consensus. 
La session dure jusqu’a ce que la decision soit prise. 

• Le developpement non planifie d’un petit prototype pour eclairer une 
incertitude technique et permettre une estimation des charges plus precise, 
appele spike par XP. 
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7.73 La gestion des connaissances dans un projet agile 

L’origine des methodes ou techniques agiles est souvent empirique, experience 
reussie ou malheureuse, dont on a tire les lemons. Meme si toutes les methodes ne 
mettent pas l’accent sur le bilan des projets et la capitalisation d’experience, la 
gestion des connaissances occupe une place non negligeable dans les approches 
agiles. 

II y a en particulier trois dispositions d’apprentissage collectif qui doivent etre 
mentionnees. 

D’abord, le compagnonnage qui favorise une transmission de savoir-faire 
entre developpeurs. La mise en binome, qui oblige a expliciter ses propres choix, 
ainsi que l’accompagnement des juniors par des developpeurs plus experimentes, 
augmentent la circulation des connaissances. 

Ensuite, la mobilisation ponctuelle de Pequipe, notamment en cas de probleme 
important lors d’une iteration de developpement, peut profiter a tous. 

Enfin, un des principes du Manifeste Agile est une incitation a la reflexivite 
pour l’equipe, c’est-a-dire une reflexion collective periodique pour ameliorer le 
fonctionnement du groupe. 

II convient cependant de souligner que generalement une telle dynamique 
d’apprentissage reste circonscrite au groupe de projet, done temporaire, et qu’on 
ne peut compter que sur une transmission individuelle d’un projet a l’autre. 

Ainsi s’acheve la presentation des differents aspects du pilotage. La mise en 
pratique est decrite au chapitre 12 et illustree au chapitre 15 avec l’outil MS Project. 




La maHrise de la qualite 


8.1 LA PROBLEMATIQUE DE LA QUALITE 

Sous des formes differentes, liees au contexte de production, la qualite est une 
notion tres ancienne 1 . Elle comporte deux aspects complementaires, que nous 
percevons clairement dans l’organisation des corporations au moyen age : un 
volet collectif et un volet individuel. Chaque corps de metier edicte des regies, 
dont la transmission est assuree par le systeme de formation des compagnons ; 
celle-ci s’acheve par la realisation d’un chef-d’oeuvre, qui, pour personnel qu’il 
soit, doit respecter les normes de la profession. La satisfaction individuelle de la 
belle ouvrage, du travail bien fait, s’integre dans l’objectif de defense du metier. 

Cette organisation de la qualite a disparu avec la production industrielle. 
L’ouvrier n’est plus en contact avec le client ; il n’agit que sur une parcelle du 
produit ; les regies jadis transmises par les organisations professionnelles se sont 
perdues. Les enjeux economiques de la qualite sont cependant pergus assez vite 2 . 
Les premieres normes nationales de fabrication apparaissent dans le domaine 
militaire : sous la Revolution, le gouvemement fait fabriquer du materiel de 
mesure devant etre utilise dans toutes les fabriques de munitions. Cela conduit 
a imposer des dimensions standard permettant l’interchangeabilite des fusils 
et des munitions. Au XX e siecle, la preoccupation de la qualite va connaitre un 

1. « Si un magon a construit une maison et que celle-ci n’est pas suffisamment solide et que la 
maison s’ecrase et tue ses occupants, le magon devra etre tue » trouve-t-on dans le code d’Ham- 
mourabi, roi de Babylone ayant vecu plus de 17 siecles avant notre ere ! Les Pheniciens cou- 
paient la main des artisans ayant viole de fagon repetitive leurs standards de qualite... 

2. « Si nos usines, par un travail soigne, assurent la qualite de nos produits, il sera de l’interet des 
etrangers de s’approvisionner chez nous et l’argent affluera dans le royaume » ecrit Colbert en 
1664 dans un rapport a Louis XIV. 
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developpement sans precedent. On peut distinguer quatre etapes que nous avons 
qualifiees d’apres la theorie apparue durant cette periode : Inspection, Controles 
statistiques, Qualite totale, Assurance Qualite. 

Premiere etape (1900-1920) : Inspection. Les inventions techniques ont 
permis un foisonnement d’applications industrielles. La productivity passe au 
premier rang des preoccupations. Aux Etats-Unis, les grandes entreprises telles 
la compagnie Ford mettent en oeuvre a une large echelle les principes d’organi- 
sation scientifique du travail (OST) edictes par F.W. Taylor. L’objectif est de faire 
fabriquer des produits de plus en plus complexes par des ouvriers non qualifies. 
L’autocontrole est remplace par une inspection systematique permettant d’isoler 
les produits defectueux. Celle-ci est souvent une detection visuelle des defauts 
apparents : elle s’effectue en bout de chaine sur les produits finis. Le dispositif de 
production distingue nettement concepteurs, ouvriers et inspecteurs. 

Deuxieme etape (1920-1950) : Controles statistiques. En 1920, la Western 
Electric doit renoncer a mettre en oeuvre un nouveau central telephonique, a 
cause du nombre de defauts qu’il contient. Et pourtant, durant toute la produc- 
tion de ce central, les inspecteurs etaient aussi nombreux que les ouvriers ! La 
Compagnie Bell Telephone cree alors un departement Qualite, avec notamment 
G. Edwards et W. Shewhart. Le premier va developper l’idee que la qualite doit 
etre geree : il cree la notion d’assurance qualite. Le second introduit la statis- 
tique comme moyen de maitrise de la qualite. Son objectif est de determiner le 
nombre minimal d’unites a controler sur un lot de produits finis avant de pouvoir 
raisonnablement declarer le lot bon ou mauvais. Ces controles statistiques se 
repandent, particulierement dans l’industrie d’armement pendant la deuxieme 
guerre mondiale, sous le nom de controle statistique de la qualite 1 . Ces methodes 
servirent a etablir les military standards, normes militaires s’imposant a tous les 
fournisseurs. Les lots ayant un pourcentage d’unites defectueuses plus eleve 
qu’une limite contractuelle sont rejetes ; les autres sont acceptes. Le taux depend 
de l’historique des livraisons de chaque foumisseur. A partir des annees 
cinquante, ces methodes vont se repandre dans les industries europeennes. En 
France, elles seront particulierement soutenues par l’AFCIQ, Association 
frangaise pour le controle industriel et la qualite. 

Troisieme etape (1950-1960) : Qualite totale. En 1950, A.V. Feigenbaum 
publie un ouvrage relatant ses experiences de developpement de la qualite totale 
a la General Electric 2 . II sera nomme quelques annees plus tard directeur de 
toutes les unites de production de la General Electric (electronique, automobile, 
chimie, navigation aerienne, etc.). Le terme « total » s’oppose aux controles 


1. SQC : Statistical Quality Control. 

2. TQC : Total Quality Control. 
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partiels de la qualite, ou celle-ci est congue comme une activite de controle 
technique specialisee. Les dix principes de la qualite totale sont les suivants : 

1. La qualite ne releve pas du seul critere technique et doit faire l’objet 
d’une application systematique dans toute l’entreprise. 

2. La qualite ne pourra etre l’affaire de tous que si les dispositions qualite 
sont congues de maniere a soutenir simultanement le travail individuel et 
celui des equipes. 

3. L’ amelioration de la qualite concerne non seulement la fabrication, mais 
egalement la vente, le marketing, la conception des produits et les servi- 
ces fonctionnels. 

4. Le processus d’application de la qualite doit se faire en pensant constam- 
ment a l’acheteur et non en fonction des imperatifs de vente ou d’effica- 
cite de la production. 

5. La qualite et le cout ne doivent pas etre pergus comme concurrents : le 
meilleur moyen de fabriquer plus vite et moins cher consiste a ameliorer 
la qualite des produits. 

6. L’ amelioration de la qualite n’est pas une operation ponctuelle, comme 
par exemple eliminer les vieilles methodes de controle de la qualite. Elle 
se congoit, s’evalue et se gere continument. 

7. L’ amelioration de la qualite ne repose pas sur le seul travail d’un specia- 
liste ; elle ne peut etre atteinte qu’avec la participation active de tout le 
personnel. 

8. L’ amelioration de la qualite augmente la productivity car elle elimine des 
dysfonctionnements existants. 

9. La qualite doit faire l’objet d’une gestion aussi directe et efficace que la 
production ou la finance. 

10. Les principes ci-dessus decoulent de la mise en place d’une politique 
claire de gestion de la qualite orientee vers la clientele. 

La qualite totale, qui elargit et complete le controle statistique, regoit un 
accueil tres favorable au Japon. L’industrie japonaise d’apres-guerre, ruinee, 
dirigee par de nouvelles equipes issues de la production ou du commercial, four- 
nissait des produits de qualite mediocre au regard des standards americains. Elle 
ne pouvait envisager la conquete des marches occidentaux qu’au prix d’une forte 
amelioration de la qualite. Avec deux statisticiens disciples de Shewhart, 
W.E. Deming et J.M. Juran, A.V. Feigenbaum se rend frequemment au Japon 
pour former les cadres a la maitrise de la qualite. Une association d’ingenieurs 1 


1. La JUSE : Japanese Union of Scientists and Engineers. 
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creee apres guerre diffuse les methodes americaines. Cependant, les Japonais 
comprennent vite 1’impasse d’ordre methodologique dans laquelle on s’enferme 
si Ton assimile qualite et science exacte. En effet, on va alors multiplier les proce- 
dures de verification. Les pesanteurs administratives imposees par les inspecteurs 
entrainent a la fois pertes de temps et rejet par les acteurs. Ce constat conduit a 
la creation en 1962 sous l’impulsion du chercheur K. Ishikawa, alors a la tete de 
la JUSE, du premier cercle de qualite. Vingt ans plus tard, il y en aura 140 000. 

Le cercle de qualite est defini comme « un petit groupe permanent et 
homogene, compose de cinq a dix volontaires appartenant a une meme unite 
organique (atelier, bureau, service, laboratoire, reseau de vente) ou ayant des 
preoccupations professionnelles communes. Anime par le plus proche respons- 
able hierarchique direct et agissant en liaison avec un specialiste facilitant le 
dialogue, le cercle se reunit regulierement afin d’identifier, analyser et resoudre 
les problemes de son choix concemant la qualite, la securite, la productivity, les 
conditions de travail, etc. »L Les cercles de qualite mettent pres de vingt ans a 
penetrer en France : il y en a eu jusqu’a 40 000, avec des degres d’activite divers. 
Ils ont permis de faire sortir de fagon pratique la preoccupation de la qualite des 
seuls departements Qualite. Ils ont favorise le deplacement de l’attention du 
produit vers le processus de production. L’AFCIQ et l’AFCERQ fusionnent au 
debut des annees 90 pour former le MFQ, Mouvement frangais pour la qualite. 

Quatrieme etape (1960-1990) : Assurance Qualite. La diffusion des principes 
qualite a tous les acteurs va franchir un nouveau pas. En 1961, P.B. Crosby, en 
collaboration avec G. Borel de LMT, lance le concept de zero defaut dans la 
societe Martin Marietta : les premiers echecs dans le domaine spatial ont montre 
que la majorite des defauts sont le resultat d’erreurs humaines ; c’est done sur 
l’homme qu’il faut consacrer ses efforts. Crosby a ensuite, en tant que directeur 
qualite d’ITT, elabore un programme zero defaut. Celui-ci comprenait notam- 
ment la suppression de nombreux controles, afin de responsabiliser l’operateur 
pour qu’il fasse bien des la premiere fois. Le zero defaut represente la conformite 
complete aux specifications. 

On passe ainsi progressivement d’une forme inactive de la qualite (detecter le 
defaut a posteriori) a une forme active de prevention methodique et systemati- 
que des sources de non-qualite que Ton appelle assurance qualite. En 1988, se 
cree l’AFAQ, Association frangaise d’assurance qualite. Cette evolution dans la 
conception de la qualite s’accompagne d’une evolution des normes : des normes 
de specification (caracteristiques techniques du produit), on est passe d’abord a 
des normes modelisant l’attente de l’utilisateur, ce qui permet d’eviter que la 
norme subisse la meme obsolescence que la technologie (modele OSI), puis a 
des normes portant sur la gestion de la qualite dans l’entreprise (IS09000). On 


1. Brochure de presentation de l’AFCERQ, Association frangaise pour les cercles de qualite. 
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distingue ainsi plusieurs niveaux de norme. Ce point est developpe plus loin 
(paragraphe 8.3). 

Aujourd’hui, la qualite totale, preventive et couvrant l’ensemble des activites 
de l’entreprise, est pratiquee par plus de 80 % des entreprises nippones. Elle 
rencontre un interet croissant dans les grandes entreprises europeennes et ameri- 
caines. Quelques exemples : dans le secteur automobile, Renault, apres un 
redressement spectaculaire, fait maintenant figure de reference ; un Institut 
Renault de la Qualite a ete mis en place pour les cadres. Rank Xerox, en dix ans, 
a divise par treize le nombre de pieces defectueuses et ameliore de 40 % la perfor- 
mance de ses equipements grace a son programme qualite totale. 

On peut dire en conclusion que les concepts qualite apparus depuis pres d’un 
demi-siecle prennent forme lentement dans les entreprises ; ils correspondent a 
un changement profond dans les relations internes de l’entreprise comme dans 
ses relations avec ses partenaires (clients, fournisseurs, prescrip teurs...). Ainsi le 
professeur Ishikawa expose le Company Wide Quality Control 1 (CWQC) a travers 
quatre principes opposes a des pratiques courantes : 

1. La qualite d’abord ( quality first ) au lieu du profit tout de suite (profit first). 

2. Le marche doit rentrer dans l’entreprise ( market in) et non l’entreprise 
ecouler sur le marche des produits conqus sans reference au marche 
( product out). 

3. Tout processus est le foumisseur d’un autre processus (next process is a 
consumer) par opposition au produit congu par un seul processus : c’est la 
mise en place de relations de type client-fournisseur a l’interieur de 
l’entreprise. 

4. La maitrise des faits ( fact control) : toute production doit pouvoir etre 
controlee par l’identification de grandeurs mesurables. 


8.2 LE VOCABULAIRE DE LA QUALITE 

La norme AFNOR 2 X50-120, qui definit les principaux termes relatifs a la 
qualite, propose la definition suivante. La qualite est « l’ensemble des proprietes 
et caracteristiques d’un produit ou service qui lui conferent l’aptitude a satisfaire 
des besoins exprimes ou implicites ». Ainsi la qualite ne se mesure pas dans 
l’absolu, mais par rapport a un besoin. Que l’on soit ou non dans un contexte 


1. Maitrise de la qualite dans l’entreprise tout entiere. 

2. Association Frangaise de Normalisation, Tour Europe, Paris La Defense. 
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contractuel, les clients et les besoins doivent etre identifies. Cette definition est 
le resultat d’une reflexion qui s’est faite en trois etapes. 

D’abord, on definit des normes et on verifie la conformite. Puis, on decouvre 
que le nombre de rebuts est eleve, on ameliore alors le processus de fabrication. 
Enfin, on s’apergoit que les clients ne sont pas satisfaits par des produits tecbni- 
quement bons et que les attentes doivent etre prises en compte. Ni le client, ni 
le foumisseur ne peuvent attendre la livraison pour decouvrir que le produit 
n’est pas satisfaisant. L’un et 1’ autre ont interet a preciser les facteurs qui servi- 
ront de base a l’appreciation de la qualite. Cela conduit a une negotiation 
devant aboutir a un compromis. En effet, quand le client cherche a preciser les 
criteres de jugement, il est conduit a identifier des fonctionnalites qui s’ajoutent 
a l’expression brute du besoin (exemple : aide en ligne) ainsi que des precedes de 
fabrication (exemple : utilisation d’un atelier de genie logiciel pour assurer la 
portability) . Ces fonctionnalites et ces precedes induisent souvent une charge 
supplementaire (couts, delais). II faut done trouver un compromis entre le 
niveau des exigences et le prix consenti. 

L’approche negociee de la qualite conduit a identifier deux types de role : 

• le maitre d’ouvrage (le client) — en anglais project owner — definit les 
facteurs qualites qui caracterisent le produit attendu ; 

• le maitre d’oeuvre (le foumisseur) — en anglais project manager — definit 
les facteurs qualite du processus de developpement a mettre en oeuvre pour 
produire ce qui a ete convenu, e’est-a-dire des fonctionnalites assorties 
d’un couple cout-delai. 

Les dispositions negociees se traduiront par un plan qualite, « document enon- 
gant les modes operatoires, les ressources et la sequence des activites liees a la 
qualite, se rapportant a un produit, service, contrat ou projet particulier ». 
Precedemment appelle plan assurance qualite (PAQ), il contient d’une part les 
caracteristiques qualite du produit et d’autre part les dispositions qualite portant 
sur le processus. Il est presente plus longuement au paragraphe 8.7. 

La relation maitre d’oeuvre-maitre d’ouvrage s’inscrit dans les dispositions 
d’ assurance qualite (figure 8.1), definie comme « l’ensemble des actions preetablies 
et systematiques necessaries pour donner la confiance appropriee en ce qu’un 
produit ou un service satisfera aux exigences donnees relatives a la qualite ». 

La gestion de la qualite s’est developpee ces demieres annees et a fait l’objet 
d’un ensemble de normes applicables a tout secteur d’activite notamment la 
norme IS09000, que nous presentons ci-dessous (paragraphe 8.3.3). 

Les dispositions prises par le foumisseur pour assurer et gerer la qualite sont 
rassemblees dans un manuel qualite. On en decrit le contenu au paragraphe 8.6. 
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Figure 8.1 — Les dispositions de I'assurance qualite. 


8.3 LA NORMALISATION DE LA QUALITE : NORMES AFNOR ET ISO 

8.3.1 La typologie des normes 


La normalisation trouve son origine dans le besoin d’interchangeabilite. Si l’on 
a pu acheter une pellicule photographique et la mettre sans probleme dans 
n’importe quel appareil, c’est parce que leurs dimensions et leurs tolerances ont 
fait l’objet de normes intemationales. 

Ce type de norme, que l’AFNOR qualifie de norme du premier type, decrit 
l’etat d’une technique, en specifiant les caracteristiques des elements constitutifs 
et leur assemblage. 

Pour certaines exigences, ce type de norme est aujourd’hui depasse. Ainsi, il 
y a quelques decennies, les normes de fabrication d’une chaise portaient sur les 
caracteristiques du bois, la resistance de la colle utilisee, etc. Cet enonce 
presente l’inconvenient majeur d’etre lie a la technologie utilisee : une evolu- 
tion de l’etat de l’art oblige a modifier la norme. 

C’est pourquoi on a prefere definir des normes du deuxieme type, se presentant 
sous la forme d’un modele. Les jouets destines aux enfants de moins de trois ans 
et portant la norme NF doivent satisfaire a des exigences de securite et 
d’hygiene, quels que soient leurs dimensions ou materiaux. Une cuisiniere a gaz 
obeit generalement a des normes de premier type (dimensions normalisees) et a 
des normes de deuxieme type (securite, repartition des temperatures dans le four, 
etc.). 

Un troisieme type de norme est apparu, pour repondre a une exigence de regu- 
larity dans la production d’une entreprise : ce sont des normes portant sur l’orga- 
nisation et la gestion de la qualite elle-meme. Elies ne sont done plus liees a un 
produit donne, mais s’appliquent a tout type d’entreprise et de projet. 
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Dans le domaine systeme d’information, nous retrouvons ces trois types de 
normes : 

• Les normes de type « caracteristiques » sont celles qui sont specifiques a 
une entreprise : presentation des ecrans, plans types de documentation, 
utilisation d’outils specifiques (atelier de genie logiciel, outil de suivi de 
projet, de maquettage. . . ), structure des noms (de rubrique, de programme, 
de document). 

Ces normes sont definies par reference a des standards de fait — l’ergo- 
nomie Windows — ou par un organisme de normalisation — l’OMG 1 
pour le langage de modelisation UML, 1’ISO 2 pour le modele Entite/rela- 
tion. Elies obeissent a un besoin d’interchangeabilite : pouvoir passer de 
fagon transparente d’un projet a l’autre, ou d’une application a l’autre. 
Elies doivent etre stables et rigoureusement respectees. 

• Parmi les normes de type « modele », on trouve d’abord le modele general 
de communication OSI. On trouve egalement les methodes de concep- 
tion, qui ne decrivent pas la solution mais des exigences (elaboration de 
modeles, de maquettes, de prototypes, approche par niveau...). Elies 
creent une culture commune. 

• La principale norme de type « systeme qualite » est IS09000, dont la 
derniere version date de 2000 et qui sert de base a la certification qualite. 
La norme IS010006, qui porte sur la qualite du management de projet, peut 
egalement etre rangee dans cette categorie. Elle est decrite au chapitre 16. 


8.3.2 Les normes AFNOR 

NF X50-120 (septembre 1987) definit le vocabulaire qualite et les termes anglais 
correspondants. 

NF X50'126 (octobre 1986) propose un guide devaluation des couts de la 
non-qualite. Des etudes ont montre que la non-qualite, variable d’une entreprise 
a l’autre, represente en moyenne 10 % du chiffre d’affaires. La norme propose un 
cadre devaluation (figure 8.2). 

Elle distingue : 

• les anomalies internes : ce sont les defauts detectes au cours du processus 
de production, avant la mise a disposition du produit ; 


1. Object Management Group. 

2. International Standard Organisation. 
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Figure 8.2 — Evaluation des couts de la qualite et de la non-qualite. 


• les anomalies extemes : elles sont signalees par le client et necessitent une 
prise en charge des reclamations et de la maintenance corrective ; 

• la detection des defauts, c’est-a-dire les moyens materiels et humains pour 
rechercher d’eventuelles anomalies ; 

• la prevention, c’est-a-dire le dispositif necessaire pour prevenir les anomalies. 

833 La norme IS09000 

La croissance du commerce international apres la Deuxieme Guerre mondiale a 
pousse les gouvemements a s’accorder sur un minimum de normes techniques 
pour faciliter les echanges internationaux. Des instances intemationales mais 
non gouvemementales se sont mises en place a l’ONU, notamment 1’ISO. Ces 
normes constituent une reference d’application non obligatoire. 

Sur le plan europeen, le CEN 1 a vu son role s’amplifier en 1985, quand le 
conseil des ministres de la CEE a decide que la reglementation communautaire 
elaboree par la Commission devrait se bomer a fixer les exigences principales de 
securite, en laissant le soin aux organismes de normalisation de definir les 
normes europeennes. Certains appels d’offres, notamment communautaires, 
exigent le respect des normes. 

La particularity de la norme IS09000 est de s’interesser non aux produits 
mais a l’organisation de l’entreprise. Le principe de base est qu’un systeme de 
production, comme le deroulement d’un projet, se trouve place dans un environ- 
nement qui a un impact non negligeable sur les resultats. D’ou l’idee que la 
qualite doit etre geree de fagon permanente, en dehors de tout projet, par un 
systeme qualite, c’est-a-dire l’« ensemble de la structure organisationnelle, des 
responsabilites, des procedures, des precedes et des ressources pour mettre en 
oeuvre la gestion de la qualite ». La prevention est done privilegiee, au lieu de se 
limiter a la recherche de non-conformites. 


1. Comite europeen de normalisation, situe a Bruxelles. 
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Les principaux concepts sont definis de la fagon suivante : 

• Politique qualite : engagement et principes de la direction generale en 
matiere de qualite. 

• Gestion de la qualite : ensemble des activites qualite qui relevent de la 
direction generale, c’est-a-dire la planification des actions qualite, l’allo- 
cation de ressources pour la qualite, l’organisation de la qualite et revalua- 
tion. Son objectif est de rechercher un equilibre economique, en evitant 
aussi bien la sous-qualite que la sur-qualite. 

• Systeme qualite : c’est le dispositif organisationnel (responsabilites et 
procedures). 

• M aitrise de la qualite : ce sont les activites et techniques mises en oeuvre 
pour suivre un processus et eliminer les causes d’anomalie. Par exemple, les 
activites mises en oeuvre sur un projet specifique relevent de la maitrise. 

• Assurance qualite : ce sont les dispositions qui visent a donner confiance 
dans le fait que le produit du service sera de qualite, soit a la direction 
generale (assurance qualite interne) soit au client (assurance qualite 
exteme). L’ assurance qualite implique la formalisation et le controle. 


8.4 LA QUALITE DES SYSTEMES ^INFORMATION 

C’est une preoccupation relativement recente. Les premieres normes relatives au 
logiciel sont apparues au debut des annees soixante-dix aux Etats-Unis sous l’impul- 
sion des militaires, puis de 1’IEEE 1 . Elies portent sur les langages (Cobol-ANS) et les 
structures de donnees (Codasyl). Elies se sont ensuite largement developpees. 
Citons notamment la norme ISO12207 qui definit les etapes de developpement 2 , 
selon le decoupage classique presente au chapitre 2 (paragrapbe 2.5). 

La notion de qualite des logiciels est issue des industries aeronautiques et 
spatiales, preoccupees de fiabilite. A la fin des annees quatre-vingt, l’importance 
des budgets informatiques, la place des applications dans le fonctionnement de 
l’entreprise, la part dominante consacree a la maintenance des logiciels et les 
problemes rencontres dans la plupart des grands projets informatiques ont porte 
la qualite des systemes d’information au rang des preoccupations majeures dans 
les entreprises. 


1. Institute of Electronics and Electrical Engineers. 

2. Software lifecycle process. 
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On peut considerer que la partie logicielle d’un systeme d’information est un 
produit ; il presente toutefois des caracteristiques qui marquent la problematique 
de sa qualite : 

• il est immateriel ; 

• il est reproductible ; 

• il necessite une maintenance ; 

• il possede une dimension subjective. 

C’est un produit immateriel : personne n’a jamais vu un logiciel, on ne le 
pergoit qu’a travers les representations que sont le code et la documentation. On 
peut s’en faire une idee en essayant d’imaginer de faqon precise, par exemple 
pour en faire une image, une maison, a partir d’une simple description litterale. 
Cela demande un effort d’abstraction important, pour un objet par ailleurs farm- 
Her, ce qui donne une idee de la difficult^ a laquelle on se heurte dans le cas d’un 
logiciel. 

Par ailleurs, le passage d’une representation a l’autre (documentation/code) 
pose le probleme de leur fidelite : des erreurs sont susceptibles de s’introduire. 

C’est un produit reproductible : la reproduction en serie d’un logiciel ne pose 
aucun probleme. Le processus de fabrication est un processus de fabrication 
unitaire, ce qui est profondement different des industries de masse ou est nee et 
s’est ancree la reflexion qualite. Dans le domaine industriel, le processus de 
production devait assurer au meilleur cout la reproduction d’un modele. La 
qualite est mesuree par la ressemblance du produit avec le modele. Pour un logi- 
ciel, tout l’effort doit porter sur la conception et la mise au point du modele. 
Meme si les methodes de conception ont formalise des regies, des techniques, 
une demarche, reutilisables en partie ou en totalite sur chaque projet, l’application 
de la methode ne garantit pas le resultat. La difference de nature entre methode 
de conception de systeme d’information et methode industrielle, au sens d’un 
bureau des methodes dans une usine, peut etre representee par la difference 
entre les deux consignes : « elaborer le modele conceptuel du futur systeme » et 
« reproduire fidelement le modele conceptuel client ». 

La qualite etant definie par l’aptitude d’un produit ou d’un service a satisfaire 
les besoins des utilisateurs, une des grandes difficultes en systeme d’information, 
du fait de l’immaterialite des logiciels, est d’identifier les utilisateurs et leurs 
besoins. 

Le cout d’un logiciel ne se limite pas au cout de developpement, mais doit tenir 
compte du cout de maintenance. Differentes etudes ont montre que lorsqu’une 
erreur coute un franc si elle est detectee a l’etape de conception, elle en coutera 
pres de quarante a l’etape de realisation et plus de cent en maintenance corrective. 
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Par ailleurs, une partie de la maintenance evolutive provient des limites de la 
conception. 

Un systeme d’information fait partie d’un systeme socio-technique : la 
qualite pergue comporte, outre sa dimension objective qui est la conformite aux 
specifications du cahier des charges, une dimension subjective dependant du 
contexte relationnel. Cet aspect fait qu’une partie de la qualite d’un systeme 
d’information, comme dans le domaine des services, est concomitante a la 
production et ne se retouche pas a posteriori. 

Les caracteristiques d’un systeme d’information expliquent la lenteur de 
diffusion de la demarche qualite, ainsi que les evolutions dans ^interpretation 
des principes qualite. Les annees quatre-vingt ont ete marquees par des essais- 
erreurs. Les annees 90 sont celles de la mise en oeuvre effective. 

8.5 LES FACTEURS ET LES INDICATEURS DE LA QUALITE D UN SYSTEME 
D’INFORMATION 

83.1 Les facteurs qualite d’un systeme d’information 

Dans une premiere approche, on peut considerer un logiciel sous deux angles : 
les fonctions qu’il realise et les caracteristiques de son utilisation. 

Un logiciel remplit certaines fonctions : calcul de paie, suivi des consomma- 
tions, elaboration de facture... Elies sont decrites au travers des differents mode- 
les de representation du systeme d’information. On ne peut parler de qualite si la 
fonction attendue n’est pas executee correctement. 

L’utilisation d’un logiciel comprend sa manipulation, les conditions de son 
exploitation, la correction des erreurs residuelles (maintenance corrective) et les 
evolutions fonctionnelles (maintenance evolutive). 

Les exigences vont etre differentes selon : 

• la duree de vie du logiciel ; 

• le caractere critique ou non des erreurs (logiciel de jeu ou logiciel de 
comptabilite) ; 

• le type d’utilisateur. 

Ces caracteristiques correspondent a des besoins du client tout aussi fonda- 
mentaux que les fonctions realisees par le logiciel. Or, elles sont en general 
exprimees de fagon partielle. 

B.W. Boehm a propose, vers le milieu des annees soixante-dix, une premiere 
caracterisation de la qualite. 
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Un logiciel doit etre : 

• utilisable en l’etat ; 

• maintenable ; 

• portable. 

J. McCall, de la General Electric, a raffine la definition de Boehm dans son 
ouvrage Factors in Software Quality (Facteurs de la qualite du logiciel) paru en 
1978. II a introduit deux elements : 

• une typologie des facteurs, selon differents points de vue ; 

• des niveaux d’expression allant du qualitatif au quantitatif. 

On distingue ainsi trois niveaux de description : 

1 . les facteurs correspondent a un besoin ; 

2. les criteres sont des caracteristiques du logiciel, associees aux facteurs ; 

3. les metriques sont des variables permettant de mesurer l’atteinte d’un critere. 

La demarche consiste done, au cours d’un dialogue maitre d’oeuvre-maitre 
d’ouvrage, a expliciter les facteurs correspondant a la qualite attendue, puis a 
preciser les criteres correspondants et enfin a determiner les metriques. 

Celles-ci doivent etre simples, fiables et faciles a auditer. La simplicity de la 
mesure signifie que le phenomene ou l’effet retenu peut etre mesure de fagon peu 
couteuse, dans un temps court et de fagon aisement comprehensible. La fiabilite 
est la capacite a reproduire la meme valeur sur les memes elements se rapportant 
a la meme periode. Elle ne doit pas dependre de celui qui effectue la mesure. La 
facilite d’audit signifie qu’un tiers independant peut verifier la bonne application 
des regies et procedures de mesure. Celles-ci doivent etre explicites. 

Les facteurs qualite (d’apres Boehm-McCall) sont repartis selon quatre 
points de vue : fonctionnel, utilisation, maintenance et economique. 

Le point de vue fonctionnel, parfois appele conceptuel, est celui des besoins 
fonctionnels. 

II comporte trois facteurs : 

1. la pertinence ; 

2. 1’ adequation; 

3. la generality. 

La pertinence est la capacite de repondre au probleme de l’entreprise. C’est le 
facteur dont la reponse est la plus specifique de chaque projet. Pour trouver criteres 
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et metriques associes, il faudra s’interroger sur l’impact du systeme d’information 
sur la gestion de l’entreprise. 

L’adequation est celle du logiciel a l’organisation et aux procedures. Applica- 
tions informatiques et procedures de travail doivent faire un tout. Deux points 
sont a etudier particulierement : la prise de decision et les controles. L’automati- 
sation complete est rarement possible. Certains cas particuliers relevent d’une 
decision humaine, moins couteuse et capable de traiter des situations imprevues. 
De meme, la securite du systeme d’information, tout en s’appuyant sur les dispo- 
sitifs classiques, doit etre renforcee par des interventions humaines. 

La generalite est l’aptitude de la solution a resoudre des problemes de portee 
plus large que le contexte particulier du projet. Ce facteur est particulierement 
important dans le cas ou Ton congo it un progiciel. II est souvent recherche pour 
des domaines presentant plusieurs variantes (gestion des contrats d’assurance, 
gestion des ordres de bourse, gestion des credits...). 

Le point de vue de l’utilisation est celui de la mise en oeuvre et de Sexploita- 
tion du logiciel. II comporte cinq facteurs : 

1 . la maniabilite ; 

2. la fiabilite ; 

3. l’efficience; 

4. la confidentialite ; 

5. la couplabilite. 

La maniabilite est l’aptitude d’un logiciel a etre convivial et facile d’emploi 
pour le type d’utilisateur auquel il est destine. Ce facteur conceme les interfaces 
homme-machine, mais aussi le degre de parametrisation accessible a l’usager, les 
possibilites d’autoformation, etc. 

La fiabilite est l’aptitude d’un logiciel a accomplir sans defaillance l’ensemble 
des fonctions specifiees dans un document de reference, pour une duree d’utilisa- 
tion donnee 1 . La fiabilite suppose que le logiciel est stable et constant, meme en 
presence d’evenements non souhaites. 

L’efficience est l’aptitude d’un logiciel a minimiser l’utilisation des ressources 
disponibles. 

La confidentialite est 1’ aptitude d’un logiciel a etre protege contre tout acces 
par des personnes non autorisees, aussi bien en que hors exploitation. 


1. Norme AFNOR Z61-102. 
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La couplabilite, ou interoperability, est l’aptitude d’un logiciel a communiquer 
ou interagir avec d’autres systemes, logiciel de base ou autre applicatif. Cette 
caracteristique permet notamment l’echange de donnees avec d’autres systemes 
et leur utilisation. 

Le point de vue de la maintenance du logiciel est celui de son evolution. II 
comporte trois facteurs : 

1 . la maintenabilite ; 

2. 1’ adaptability ; 

3. la portability. 

La maintenabilite est degre de facilite avec laquelle on peut localiser et corri- 
ger des erreurs residuelles. Cette caracteristique a un effet direct sur les delais de 
maintenance corrective. Elle est liee a la duree de vie du logiciel. 

L’adaptabilite est l’aptitude d’un logiciel a evoluer facilement, si l’on veut 
modifier ou aj outer des fonctionnalites. Cette caracteristique a un effet direct sur 
les delais de maintenance evolutive. 

La portability est le degre de facilite avec laquelle on peut transferer le logiciel 
dans un autre environnement, logiciel (systeme d’exploitation, systeme de gestion 
de bases de donnees) ou materiel. Cette caracteristique a un effet direct sur les 
modifications necessaries en cas de transfert. 

Le point de vue economique est celui de la rentabilite des applications. II se 
traduit par un seul facteur prenant en compte, a la fois les couts de developpe- 
ment, les couts d’exploitation et les gains effectifs dus au logiciel : c’est Yefficacite 
du logiciel. 

Certains facteurs qualite sont antinomiques. Ainsi, une exigence elevee en 
matiere de confidentiality est souvent peu compatible avec la maniabilite. De 
meme la recherche de l’efficience maximale ne garantit ni la maintenabilite, ni 
1’ adaptability, ni la portability. 
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Figure 8.4 — Les facteurs qualite d’un systeme d’information 
selon les differents points de vue. 
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II s’agit avant tout de faire un choix et de preciser ce qui fait qu’on jugera le 
systeme « bon ». 

La definition des caracteristiques qualite a fait l’objet de la norme IS09126, qui 
s’appuie sur les travaux de Boehm-McCall. Elle retient six facteurs : capacite fonc- 
tionnelle, fiabilite, facilite d’utilisation, maintenabilite, portability et efficacite. 

85.2 Les criteres qualite d’un systeme d’information 

Chaque facteur peut etre caracterise par plusieurs criteres qualite ; un critere peut 
concourir a l’obtention de plusieurs facteurs. Certains criteres sont propres au 
projet ; c’est notamment le cas de ceux qui sont associes aux facteurs du point de 
vue fonctionnel. D’autres ont un caractere plus general. Nous allons presenter 
ces demiers, en les regroupant par facteur. 

Le facteur maniabilite comporte trois criteres : 

1 . la communicabilite ; 

2. l’exploitabilite ; 

3. la facilite d’apprentissage. 

La communicabilite est la capacite du logiciel de permettre un dialogue aise 
entre rhomme et la machine. Ce critere doit etre apprecie en fonction des utili- 
sateurs potentiels et des conditions d’utilisation. La presentation des resultats ou 
accessibilite aux commandes doivent etre adaptees. 

'Lexploitabilite est la facilite a mettre en oeuvre et a utiliser le logiciel. Ce 
critere peut induire le developpement d’aides en ligne, de reprise en cas d’erreur, 

La facilite d’apprentissage est mesuree par le temps moyen necessaire pour 
utiliser le logiciel de fagon autonome. On peut parfois demander que la majeure 
partie de l’apprentissage resulte d’une autoformation. 

Le facteur fiabilite comporte egalement trois criteres : 

1 . la complexity ; 

2. la tolerance aux fautes ; 

3. l’auditabilite. 

Le critere de complexity mesure l’effort necessaire pour comprendre et analyser 
le logiciel. La fiabilite decroit quand la complexity augmente. Celle-ci depend de 
sa construction algorithmique et de sa taille. 


8.5. Les facteurs et les indicateurs de la qualite d'un systeme d’information 


0 


Plusieurs metriques ont ete proposees pour la mesurer : 

• le nombre de lignes de code, car il est correle avec le nombre d’erreurs 
probables ; 

• le nombre d’arcs divise par le nombre de sommets sur l’organigramme du 
programme : c’est l’indicateur de complexity de structure de MacCabe ; 

• le nombre d’operateurs arithmetiques et logiques, ajoute au nombre de 
variables ; cette valeur mesure la complexity textuelle d’un programme : 
c’est la mesure de Halstead. 

Le critere de tolerance aux fautes renvoie a la possibility de limiter les effets 
d’une perturbation, d’origine interne ou exteme, sur logiciel. Les Japonais utili- 
sent le concept de poka-yoke, signifiant anti-erreur humaine. II est illustre par 
ces fiches de connexion, dont les formes rendent impossible les erreurs de bran- 
chement. 

Le principe general de la tolerance aux fautes est d’eviter que des erreurs 
soient commises (en posant ce que l’on appelle des « chiens de garde »), de veri- 
fier que des fautes n’ont pas ete commises (par exemple en recoupant certaines 
informations) et de pouvoir corriger les erreurs. 

llauditabilite est la capacite du logiciel de permettre de retrouver rapidement 
et sans difficulty la trace d’une operation ; la recherche doit pouvoir etre menee 
du haut vers le bas (reperer toutes les consequences d’un evenement donne) et 
du bas vers le haut (retrouver ce qui a permis d’arriver a un resultat). 

Le facteur efficience traduit la capacite a utiliser au mieux les ressources 
informatiques. 

Les ressources dont on peut chercher a optimiser l’utilisation sont : 

• la consommation en place memoire ; 

• la taille des peripheriques et leur vitesse d’acces ; 

• le temps d’ execution des programmes. 

Le facteur confidentiality est mis en oeuvre a travers deux criteres : 

1 . la protection du code et des donnees ; 

2. la memorisation des acces. 

La protection du code et des donnees est la limitation, en exploitation ou non, 
des acces a des personnes autorisees. 
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La memorisation des acces permet de retrouver la trace des manipulations. 
Pour cela, les acces a un programme, une zone de donnees ou un fichier doivent 
etre historises. 

Deux criteres favorisent la couplabilite : 

1 . la standardisation des donnees ; 

2. la standardisation des interfaces. 

La standardisation des donnees est la compatibility des donnees avec des stan- 
dards de representation. On peut ainsi utiliser pour les echanges monetaires 
internes d’une banque des normes interbancaires. 

La standardisation des interfaces : dans la logique de l’approche objet, il faut 
s’attacher a distinguer entre les fonctions dites publiques, c’est-a-dire pouvant 
etre appelees par d’autres applicatifs, et les fonctions privees. Les appels doivent etre 
normalises. 

Le facteur maintenabilite comporte quatre criteres : 

1 . la lisibilite ; 

2. la modularity ; 

3. la tragabilite ; 

4. l’adaptabilite. 

La lisibilite est la capacite d’un programme ou de sa documentation de pouvoir 
etre lus par d’autres personnes que leur auteur. Ils sont consideres comme lisibles 
si on peut les comprendre par simple lecture. La lisibilite depend d’une part du 
vocabulaire utilise et de l’expression ecrite, d’autre part de l’absence d’elements 
mal definis, c’est-a-dire necessitant pour etre compris des connaissances pream- 
bles ou des informations complementaires. Les elements superflus doivent etre 
evites. La lisibilite facilite la maintenance des programmes. 

La modularity d’un logiciel represente l’independance de ses composants. On 
peut distinguer deux niveaux. La modularity des specifications se traduit par des 
fonctionnalites bien identifiees avec leurs relations et par une autonomie par 
rapport a l’environnement materiel et logiciel. La modularity des composants 
logiciels permet de modifier un composant sans effet sur les autres. 

Le critere de tragabilite vient des industries ou il est parfois necessaire de retrou- 
ver l’origine de chaque element monte sur le produit fini (quel foumisseur l 
quelle livraison ? quel lot ?...), notamment l’aeronautique. Dans notre domaine, 
la tragabilite traduit l’existence de liens entre les differentes representations 
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graphiques et textuelles d’un logiciel. Par exemple, elle permet de savoir ou se 
retrouve tel objet ou telle operation du modele conceptuel. 

Le critere adaptabilite met en jeu la notion d’expansibilite, c’est-a-dire la 
possibility d’augmenter les zones de donnees et la taille des programmes. C’est 
un des avantages majeurs des systemes de gestion de base de donnees relation- 
nels par rapport aux systemes hierarchiques ou reseaux. Ce critere inclut la possi- 
bilite d’identifier facilement les impacts dans tous les programmes touches. 

Le facteur portabilite se decline selon trois criteres : 

1 . la banalite d’emploi ; 

2. l’independance ; 

3. la qualite de la documentation. 

Le critere de banalite d’emploi s’applique a une fonction et traduit son inde- 
pendance par rapport a une application. Certaines fonctions sont classiquement 
banalisees, par exemple, les transformations de format de date ou le calcul du 
nombre de jours entre deux dates donnees. Les parametres de reference sont 
geres dans des tables externes. 

Le critere d’independance est le degre de liberte du logiciel par rapport a 
l’environnement logiciel ou materiel et l’absence de liens structurels. Ainsi, 
l’independance par rapport a un systeme de gestion de bases de donnees necessi- 
tera par exemple l’externalisation de tous les acces et leur localisation dans un 
sous-programme unique. 

La qualite de la documentation porte sur le fond ou sur la forme. Les documents 
sont les principaux produits des etapes de conception et constituent des representa- 
tions du logiciel (documentation d’utilisation, Sexploitation et de maintenance). 
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Figure 8.5 — Les criteres qualite associes aux differents facteurs 
qualite d'un systeme d'information. 
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Sur le fond, il faut eviter trois ecueils : la contradiction entre deux parties d’un 
document ou entre deux documents ; le silence, c’est-a-dire l’absence d’elements 
importants ou permettant la comprehension et Yambiguite, a savoir une expres- 
sion donnant lieu a des interpretations multiples. 

Sur la forme, il faut minimiser quatre travers : la redundance, marquee par la 
presence d’elements identiques dans le meme document ou dans deux docu- 
ments ; le bruit que represente la presence d’elements superflus ; le sur 'detail, 
c’est-a-dire la presence d’elements d’un niveau de detail trop fin par rapport a 
l’objectif du document et le non-respect des normes telles qu’un plan type ou des 
normes de presentation. 


8J>.3 L’ utilisation des caracteristiques de la qualite 

Le premier interet de la demarche facteur-cri tere -mi tuque est d’offrir un cadre 
dans l’approche negociee des caracteristiques qualite. Par un examen systemati- 
que des differents aspects, il permet d’expliciter les attentes qualite des acteurs, 
ceux qui utilisent le systeme d’information (gestionnaire, utilisateur final) et ceux 
qui le font vivre (exploitation et maintenance). 

Par ailleurs, la demarche fait apparaitre d’eventuelles contradictions dans les 
exigences, resultant de la presence de facteurs antinomiques. La demarche oblige 
done a faire des choix, a hierarchiser facteurs et criteres. Pour les facteurs fonc- 
tionnels, elle favorise une projection en posant non pas la question « que voulez- 
vous ? » mais « qu’est-ce qui fera que vous serez satisfait ? ». C’est pourquoi, la 
methode de l’analyse de la valeur 1 est souvent consideree comme un des elements 
pouvant concourir a la qualite fonctionnelle des systemes d’information. 

Le second interet de la demarche facteur-critere-metrique est de mettre en 
place une liste de non-conformites a traquer tout au long du processus de deve- 
loppement par le dispositif de controle. 

Dans un projet, les facteurs, criteres et metriques resultent de la negociation 
entre le maitre d’oeuvre et le maitre d’ouvrage. Celle-ci integre les preoccupa- 
tions de cout et delais. Le resultat figure dans le plan assurance qualite. 

Voici un exemple de facteurs qualite qui sont des objectifs exprimes par la 
direction generale d’une grande entreprise de services : 

La qualite du systeme d’information devient un facteur preponderant pour la reali- 
sation des objectifs majeurs de l’ entreprise. Son evolution sera conduite en respectant 
les principes suivants : 

• ne conduire que des projets dont la rentabilite soit clairement etablie et dont la 
taille garantisse la maitrise dans des delais courts ; 


1. Normes AFNOR X 50-150, 151, 152, et 153. 
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• dans tons les nouveaux projets , mettre systematiquement en oeuvre une approche 
et une architecture client-serveur en s’appuyant sur un poste de travail banalise ; 

• s’appuyer sur le systeme existant en le deformant progressivement et continuellement ; 

• rechercher une meilleure homogeneite et une plus grande coherence, conduisant 
a l’ abandon progressif des solutions regionales particulieres . 

Ainsi, dans l’exemple ci-dessus, la rentabilite des applications peut etre 
recherchee dans la reduction des couts, par exemple, la reduction des couts 
administratifs, T amelioration de la logistique, la gestion de stock en flux tendus. 
II faut d’ autre part developper des d’activites rentables, par exemple, un soutien 
a Taction commerciale, une amelioration de la gestion du contentieux, la factu- 
ration d’un service nouveau. . . 

Pour promouvoir la couplabilite, on parle parfois du systeme d’information, 
tous les systemes devant pouvoir communiquer. Ainsi, a partir d’une station de 
travail unique, on doit pouvoir acceder a Tensemble des informations. 

L’evolutivite demandee correspond a une realite tres forte dans certains 
secteurs industriels comme Tautomobile ou, d’une annee sur l’autre, le meme 
modele se modifie. C’est egalement le cas dans Turbanisme lorsque Ton renove 
progressivement un quartier, au lieu de le raser. Dans le domaine des systemes 
d’information, cela se traduit notamment par des habillages ergonomiques, qui 
evitent de refaire les applications. 

La generalite des solutions obeit a un compromis entre coherence et 
complexite. La coherence totale dans une grande organisation est complexe. La 
coherence de Tensemble des parties communes doit coexister avec des parties 
privees specifiques. 

8.6 LE MANUEL QUALITE 

La notion et le contenu du manuel qualite ont evolue au fur et a mesure que les 
principes de l’assurance qualite etaient interpretes et experimentes pratiquement. 

II y a quelques annees, le manuel qualite contenait le savoir-faire formalise de 
Tentreprise : il se concentrait sur les aspects techniques et methodologiques du 
metier. Certaines dispositions representaient l’etat de Tart, d’autres etaient 
specifiques a Tentreprise. 

Pour TAFITEP et l’AFNOR, le manuel qualite est « un document decrivant 
les dispositions generales prises par Tentreprise pour obtenir la qualite de ses 
produits ou services » [AFITEP, 2000]. Son objectif est double : d’une part infor- 
mer le personnel sur Torganisation d’ensemble de Tactivite et notamment sur le 
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systeme qualite de l’entreprise ; d’autre part, resumer pour les clients les mesures 
adoptees pour assurer la qualite. Ce manuel est parfois considere comme un outil 
interne et exteme de promotion de la qualite de l’entreprise. 

Dans l’ingenierie informatique, on distingue parfois deux volets complemen- 
taires du manuel qualite : 

• Le manuel qualite interne comporte un volet technique (principes de mise 
en oeuvre des technologies) et un volet methodologique (par exemple 
methodes de conception, methodes devaluation des charges, guide de 
conception d’interface homme-machine. . . ). 

• Le manuel assurance qualite contient d’une part la description de [’organi- 
sation de la qualite dans l’entreprise (direction qualite, correspondant 
qualite...), d’autre part 1’ interpretation que l’entreprise a faite des diffe- 
rents points de la norme IS09000. Certains points renvoient a des points 
du manuel qualite interne. 

Le manuel qualite sert de base aux audits qualite, internes ou extemes. 

8.7 LE PLAN QUALITE 

8.7.1 La definition du plan qualite 

L’ assurance qualite cherche a generaliser le principe de la relation client-foumis - 
seur. Cela signifie que chacun dans l’entreprise (individu ou service) a toujours 
au moins un client et un foumisseur. Cette approche permet de clarifier et 
d’ameliorer les relations entre partenaires de travail. 

La relation client-foumisseur peut etre representee par un schema simple : le 
fournisseur est celui qui procure quelque chose dont a besoin le client. Derriere 
cet aspect de troc, se cache une relation souvent ambigue. La regie du jeu 
consiste a obtenir le plus possible de l’autre. Mais c’est aussi un echange de bons 
precedes dans lequel le fournisseur conseille le client. II garantit l’absence de 
vices caches. II doit foumir un produit ou un service qui reponde aux besoins 
exprimes, en s’assurant que cette expression est conforme aux besoins reels du 
client. Celui-ci s’engage a exprimer son attente de la maniere la plus claire possi- 
ble. Ils conviennent ensemble d’une mesure pertinente du resultat. Cette 
volonte d’une relation de cooperation se materialise par un contrat. 

Le plan qualite joue ce role. C’est un outil de clarification entre maitre 
d’oeuvre et maitre d’ouvrage. 
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Le plan qualite se distingue du contrat commercial sous trois aspects : 

1 . Le contrat commercial n’existe que dans les relations entre l’entreprise et 
son environnement, alors que le plan qualite est utilisable egalement dans 
les relations internes. 

2. Apres description du produit/service a foumir, des conditions financieres 
et modalites de paiement, et des conditions de livraison, le contrat 
contient toutes les clauses visant les defaillances possibles de l’une ou 
l’autre partie. Le plan qualite, au contraire decrit pour une large partie des 
dispositions visant a prevenir les defaillances. 

3. Le contrat commercial est en general de diffusion confidentielle, alors que le 
plan qualite constitue un outil de travail pour l’ensemble des acteurs du projet. 

L’AFITEP et l’AFNOR definissent le plan qualite comme un « document 
enongant les modes operatoires, les ressources et la sequence des activites liees a la 
qualite, se rapportant a un produit, service, contrat ou projet particulier » [AFITEP, 2000]. 

Aujourd’hui, le plan qualite est inclus dans le plan de management de projet. 

8.7.2 Le contenu du plan qualite 

Le plan qualite contient generalement deux parties. On y trouve d’une part la 
description — suite aux negotiations entre maitre d’oeuvre et maitre d’ouvrage 
— de la qualite attendue du futur systeme d’information, exprimee par un 
ensemble de facteurs hierarchises, assortis de criteres et metriques, ainsi que, 
d’autre part, le cycle de developpement retenu avec pour chaque etape : 

• les resultats attendus ; 

• les conditions d’acceptation de chaque resultat ; 

• les modalites de controle ; 

• la planification ; 

• l’organisation des equipes ; 

• les relations entre acteurs (roles, responsabilites, circulation d’information 
et de documents. . .) ; 

• les methodes, normes et outils utilises. 

Le plan qualite ne doit contenir que ce qui est propre au projet. Toute norme, 
procedure, methode, etc., qui s’applique a tous les projets releve du manuel 
qualite interne ou du manuel qualite. On peut en revanche faire reference a 
certains elements de ces manuels. 
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Selon la norme IS09000-3 (point 5.5.2), le plan qualite doit comprendre la 
description des points suivants ou leur reference dans d’autres documents s’ils 
ont ete decrits separement : 

• la qualite attendue du produit, exprimee a l’aide de facteurs, criteres et 
metriques ; 

• les entrees et sorties de chaque etape du cycle retenu ; 

• la nature des tests et des controles de la production ; 

• le planning des activites de verification, comprenant le calendrier et les 
ressources qui sont affectees ; 

• l’identification des responsables des differentes activites qualite, telles que 
la maitrise des modifications, la gestion des actions correctrices, etc. 

De par son contenu, le plan qualite est un document qui est une reference 
dynamique durant le deroulement du projet : il s’enrichit progressivement selon 
les phases et peut etre modifie si les besoins du client evoluent. II constitue nean- 
moins un cadre stable. 


8.8 LE CONTROLE ET LAUDIT QUALITE 

8.8.1 Le controle qualite 

Le controle qualite fait partie des dispositions d’assurance qualite. II doit etre 
mene en continu tout au long du projet sous differentes formes. II porte sur les 
produits elabores a chaque etape du projet. Ces produits sont de deux natures : 
des documents et le logiciel. 

La qualite des documents 

Les documents doivent satisfaire aux criteres qualite touchant le fond (absence 
de contradiction, silence ou ambigu'ite) et la forme (absence de redondance, 
bruit, non-respect des normes). 

Selon les acteurs impliques, les controles sont internes (les acteurs du controle 
font partie de l’equipe projet) ou externes (les acteurs ne font pas partie de la 
maitrise d’oeuvre). La philosophie generale est de tendre vers une situation ou 
l’on fait bien du premier coup. Les dispositions doivent laisser une part impor- 
tante a Y autocontrole : celui-ci sera favorise par une gestion correcte du systeme 
qualite, notamment tous les points concemant la diffusion des normes, regies, 
principes. Cependant, les controles effectues par d’autres acteurs obligent en 
permanence le redacteur a considerer son produit comme devant servir a d’autres. 
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Le plan qualite du projet prevoit differents types de controles. 

U inspection permet d’apprecier la qualite d’un document en fonction d’un 
referentiel. Le moyen utilise est la lecture du document par un individu, interne 
ou exterieur a l’equipe projet. Ce controle peut etre effectue par le chef de 
projet, par un utilisateur privilegie ou par le responsable qualite du projet. II est 
parfois assure par un autre concepteur du projet ; l’objectif est de favoriser un 
autocontrole ulterieur, par interiorisation des regies et principes d’harmonisa- 
tion, de coherence et de lisibilite. 

La lecture croisee met en jeu deux acteurs appartenant a des projets differents, 
par exemple deux sous-projets du meme projet global. Elle favorise la coherence 
entre projets ou sous-projets. 

La revue est une evaluation collective d’un document. Elle peut etre conside- 
ree comme un moyen de conforter des pratiques organisationnelles souhaitables. 
L’organisation, la conduite et le suivi d’une revue sont soumis a des regies gene- 
rales de bon fonctionnement. Les revues impliquent plusieurs personnes jouant 
un role different, par exemple : 

• Le presentateur du document est en general l’auteur ; c’est parfois le chef 
de projet. 

• Le coordinateur organise la revue ; il envoie prealablement le document a 
tous les participants, date, lieu... C’est souvent le responsable qualite du 
projet. 

• Le rapporteur est charge du compte rendu de la revue : diagnostic et actions 
correctives decidees. C’est souvent le responsable qualite du projet. 

• Le lecteur fait une lecture critique du document. Selon que le controle est 
interne ou exteme, c’est soit un membre de l’equipe projet (ou eventuelle- 
ment d’une autre equipe) soit un representant du maitre d’ouvrage. II peut 
y avoir plusieurs lecteurs, chacun pouvant representer un point de vue 
specifique. 

Pendant la conduite de la revue, tous les participants sont responsables de 
revaluation et 1’ amelioration du produit controle. Ils doivent garder a l’esprit 
qu’ils jugent un document et non une personne : les critiques doivent etre 
ciblees et mettre en relief des points necessitant un complement de travail. La 
revue ne doit pas se transformer en reunion de conception. Elle ne depasse pas 
deux heures. 

A l’issue de la revue, un compte rendu redige par le rapporteur contient trois 
parties : identification de la revue, de son objet et de ses participants ; liste 
des points et problemes souleves ; decisions et calendrier de prise en compte des 
decisions. Ce compte rendu fait partie du systeme d’information projet. 
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Les ameliorations doivent etre apportees par l’auteur initial du document. Le 
responsable qualite, ou a defaut le chef de projet, est responsable de leur mise en 
oeuvre : si les modifications sont mineures, une inspection sera suffisante. Dans 
certains cas, une nouvelle revue est organisee. Ces dispositions figurent dans le 
compte rendu. 

Le plan qualite, ou le plan de controle si celui-ci est separe du plan qualite, 
doit prevoir les differents controles prevus : 

• type de controle ; 

• objet du controle ; 

• date; 

• acteurs ou type d’acteurs. 

II doit etre mis a jour, pour integrer les aleas du projet (controle supplemen- 
taire, nouvelle revue, modification d’acteur...). 

La qualite des programmes 

Le plan de test comprend le calendrier et les modalites de preparation et 
d’execution des tests. 

Les tests unitaires, dits de « boite blanche » mettent en evidence les erreurs de 
chacun des composants ; ils sont prepares par le realisateur avant la programma- 
tion. Ils permettent de tester les differents chemins et la validite des conditions 
d’acces a chaque branche, par exemple, examen des valeurs conditionnelles, 
verification des valeurs limites... 

Les tests d’ integration detectent des erreurs d’interface entre les composants 
logiciels. Les fonctions testees unitairement sont introduites successivement. 

Les tests de validation fonctionnelle, dits de « boite noire » recherchent les 
erreurs de conception, les omissions et les non-conformites par rapport aux 
exigences specifiees. 

Ces trois types de test correspondent a trois niveaux de validation. Selon le 
modele de developpement en V, les jeux d’essais sont constitues dans l’ordre 
inverse de leur utilisation. A Tissue d’une phase de specification fonctionnelle, 
on elabore le jeu d’essai de validation fonctionnelle. Celui-ci doit donner lieu a 
une revue exteme avec la maitrise d’ouvrage. En phase d’analyse technique, on 
elabore (si possible par enrichissement d’un sous-ensemble du jeu d’essai prece- 
dent) les jeux de tests d’integration. Enfin, avant la programmation, on elabore 
les jeux de tests unitaires, a partir egalement des jeux de tests d’integration. 

Les tests effectues sur le site ou dans un environnement operationnel donnent 
lieu a une qualification. 
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8.8.2 L’audit qualite 

L’audit qualite du projet est un moyen d’evaluer la qualite du processus. L’AFNOR 1 
le definit comme « 1’examen methodique d’une situation relative a un produit, 
precede ou organisation, realise en cooperation avec les interesses en vue de 
verifier la conformite de cette situation aux dispositions preetablies et 1’ adequation 
de ces demieres a l’objectif recherche ». 

Dans les projets systemes d’information, l’audit peut prendre differentes 
formes : 

• l’audit qualite porte sur le respect des dispositions du plan assurance 
qualite ; 

• l’audit d’avancement porte sur l’etat reel du projet par rapport a son a van- 
cement annonce ; 

• l’audit fonctionnel porte sur 1’ adequation du systeme congu aux objectifs 
annonces. 

Les audits ne sont pas planifies. Ils s’appuient sur des questionnaires precis et 
concis, prepares a l’avance. Les audits internes au projet se font a la demande du 
chef de projet. Les audits extemes se font a la demande de la maitrise d’ouvrage 
ou de la direction generale. Certains audits de projet peuvent etre faits lors d’une 
procedure de certification IS09000. Nous allons aborder ce point dans le cadre 
plus large de la qualification des entreprises. 


8.9 LA QUALIFICATION DES ENTREPRISES 

8.9.1 La certification 

La qualite comporte deux aspects temporellement differents. La qualite nominale 
des produits est l’acception habituelle de la qualite : il y a correspondance avec 
les besoins et absence de defauts pour un produit precisement identifie. La regu - 
larite de la qualite, qu’il s’agisse du respect des delais, des caracteristiques du 
produit ou de la facturation... est un autre aspect. C’est celui qui est vise par la 
norme IS09000. 

Des la fin des annees soixante-dix, certaines grandes entreprises ont 
commence a faire pratiquer des audits qualite, fondes sur des normes sectorielles 
ou specifiques, chez leurs sous-traitants. Cela a conduit la plupart des pays occi- 
dentaux a mettre en place des systemes de certification de fagon a attribuer une 
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certification unique pour une entreprise donnee, homogene d’une entreprise a 
l’autre et impartiale. 

En France l’AFAQ, dont le conseil d’administration comprend l’AFNOR, 
des acheteurs, des foumisseurs, des sous-traitants..., delivre les certifications. 
Elle se compose de differents comites sectoriels. 

Fa Grande-Bretagne a instaure un organisme central accreditant les organis- 
mes de certification ; il y en a une dizaine. Fes Britanniques ont, par ailleurs, cree 
une certification specifique pour les technologies de l’information, basee non 
plus directement sur IS09000 mais sur l’interpretation qu’en a faite le projet 
TickIT. 

Fa certification est attribute au terme d’un audit qualite de l’entreprise, 
« examen methodique et independant en vue de determiner si les activites et les 
resultats relatifs a la qualite satisfont aux dispositions preetablies, et si ces dispo- 
sitions sont mises en oeuvre de fagon efficace et aptes a atteindre les objectifs »'. 

L’ audit du systeme qualite dans le domaine ingenierie des systemes d’informa- 
tion, se deroule en trois phases : 

• La preparation. Elle comprend notamment la delimitation du champ de la 
certification (toute l’entreprise, une entite, une activite dans une entite ?) 
et la constitution de l’equipe d’ audit (au moins la moitie de ses membres 
doivent etre des specialistes logiciel). 

• L’ execution. Elle comprend l’examen du manuel assurance qualite et 
l’etablissement de sa correspondance avec IS09000 ; la recherche de 
non-conformites au niveau des procedures et des instructions de travail ; 
l’examen, a titre de confirmation, de quelques projets, afin de verifier 
l’application effective des dispositions du systeme qualite ; et la presenta- 
tion or ale des resultats. 

• Le rapport d’ audit. Si le rapport a mis en evidence un nombre limite de 
non-conformites, d’importance limitee, l’entreprise obtient la certifica- 
tion apres correction des non-conformites et verification par un nouvel 
audit. Si des anomalies graves ou nombreuses ont ete decelees, l’entreprise 
doit mener une operation de mise en conformite de son systeme qualite. 

La certification est accordee pour trois ans. La plupart des societes de services, 
grandes ou moyennes, ont obtenu la certification pour tout ou partie de leurs 
entites et de leurs activites. Certaines demandes de certification proviennent des 
services informatiques internes. Ces demiers recherchent une reconnaissance 
exteme qui leur apportera en retour la legitimite interne. 


1. AFNOR X50-120. 
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8.9.2 devaluation de la maturite des entreprises 

Mai comprise, la demarche de certification peut conduire a une sur-formalisa- 
tion (mythe du controle total), a la bureaucratisation (la regie prime sur [’intel- 
ligence) et a la dispersion des efforts dans l’entreprise (l’objectif devient la 
certification et non l’amelioration constante de la qualite). 

Les entreprises japonaises trouvent le systeme trap contraignant et contraire 
a leur approche. 

Aux Etats-Unis, le SEI 1 a mis au point a la demande du DOD 2 une demarche 
devaluation de la maturite des sous-traitants. C’est le SW-CMM 3 . La premiere 
ebauche date de 1987, elle s’est affinee au fur et a mesure de son utilisation, 
surtout en Amerique du Nord et au Japon. 

Ce modele evalue les entreprises selon deux criteres (figure 8.7) : 

• la maitrise des processus ; 

• la maitrise technologique. 

Les niveaux de maitrise des processus sont au nombre de cinq : le debut, la 
repetition, la definition, la gestion et l’optimisation. 

1 . Au niveau debut, les procedures et les responsabilites sont mal definies. Les 
principes ne sont pas appliques de fagon coherente. L’entreprise a ce 
niveau rencontre d’importants problemes de couts et de delais. 

2. Au niveau repetition, l’entreprise a su mettre en oeuvre des procedures de 
gestion des couts et des delais, standard d’un projet a l’autre : evaluation 
des couts, techniques de planification, gestion des modifications. 

3. Au niveau definition, l’entreprise a mis en place un groupe specialise en 
genie logiciel, qui definit et met en oeuvre des normes et des methodes, 
ainsi que des plans de formation pour les differents acteurs. Les procedures 
sont bien comprises. 

4. Au niveau gestion, l’entreprise sait mesurer l’impact des actions entrepri- 
ses. Elle base ses decisions operationnelles ainsi que les evolutions en 
matiere de normes, organisation et methodes, sur des donnees quantifies 
qui sont analysees. 

5. Au niveau optimisation, l’entreprise a oriente son action vers 1’ ameliora- 
tion de ses processus, par des analyses rigoureuses des donnees collectees 
sur les erreurs, les couts et les ecarts par rapport aux previsions. 

1. Software Engineering Institute, de l’Universite Camegie-Mellon, situee a Pittsburgh (Pennsylvanie). 

2. Department of Defense : ministere de la Defense. 

3. Software Capability Maturity Model. 
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Les deux niveaux de maitrise technologique sont qualifies d’inefficace et efficace. 

• Au niveau inefficace, des outils peuvent etre utilises de fagon generalisee, mais 
l’entreprise n’en retire qu’un faible benefice, faute d’objectifs clairs, de forma- 
tion suffisante, de coherence entre les outils et l’exigence de rentabilite. 

• Au niveau efficace, l’entreprise sait obtenir de bons resultats de l’utilisation 
generalisee et coherente de ses outils et techniques. Selon son niveau de 
maitrise des processus, elle sera plus ou moins reguliere dans ses performances. 
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Figure 8.7 — Modele de maturite des entreprises. 


On evalue la maturite d’une entreprise avec un double objectif. On cherche 
d’une part a identifier les forces et faiblesses. On veut d’autre part susciter une 
dynamique d’amelioration des pratiques. La boucle d’amelioration peut etre 
representee par un schema tel que celui de la figure 8.8. 
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Figure 8.8 — Boucle d’amelioration de la qualite. 


Cette approche permet de concretiser des objectifs de progression. L’expe- 
rience montre qu’une majorite d’entreprises se situent au niveau un ou deux 
pour la maitrise des processus et au premier niveau de maitrise technologique. 

Une operation devaluation dure en general entre quatre et huit mois. Elle 
represente un investissement d’environ 200 jours-personne pour une entreprise 
de taille moyenne. Elle est basee sur un questionnaire devaluation des pratiques 
de Pentreprise, notamment en ce qui conceme la definition des besoins, la plani- 
fication des projets, le suivi des projets, la gestion des sous-traitants, la gestion du 
changement, etc. 
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Le modele du SEI a ete repris et adapte par les Canadiens de Bell Canada 1 et 
par un projet Esprit 2 . Ces deux modeles ne sont pas de nature publique. 

Le projet SPICE 3 , ne d’une initiative britannique en 1992, a ete mene par 
1’ISO. II integre l’acquis en matiere qualite, notamment les normes IS09000 et 
ISO12207. II a donne lieu a la norme ISO/IEC 15504 qui propose une demarche 
d’amelioration des processus 4 . 

Nous pouvons dire en conclusion que l’assurance qualite et la necessite de 
fiabiliser durablement tous les processus de l’entreprise reposent sur : 

• des objectifs explicites ; 

• une organisation du travail claire et souple ; 

• un personnel competent et motive ; 

• des methodes et des precedes de travail maitrises ; 

• une documentation precise, concise et complete ; 

• un autocontrole efficace ; 

• le maintien d’un controle minimal ; 

• la tragabilite des actions ; 

• le recueil et le traitement des anomalies et des defauts ; 

• l’analyse des causes de cette non-qualite et la mise en place de la preven- 
tion necessaire. 

L’ amelioration de la qualite doit se concevoir comme un processus dynami- 
que et non comme l’atteinte d’un objectif definitif. La certification est un des 
moyens de cette dynamique. 

Elle s’accompagne d’une evolution des concepts fondant les relations entre 
les acteurs, passant progressivement de la directivite a la participation, de la 
centralisation a la delegation, de la notion de chef a celle de manager favorisant 
l’initiative et le developpement des membres de son equipe, des rapports de 
force aux rapports de negociation, de la mise en concurrence au partenariat 
pour durer ensemble, de la faute a l’obligation de progres, du bricolage au 
professionnalisme. 


1. Modele Trillium. 

2. Modele Bootstrap. 

3. Software Process Improvement and Capability Determination. 

4. Pour plus de details, voir Morley et al., Processus metiers et S.I., Dunod, 2007, particulierement 
au chapitre 4. 
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8.10 LA QUALITE DANS LES METHODES AGILES 


Les approches agiles sont parfois opposees aux demarches d’amelioration des 
processus et de maturite des entreprises. En effet, la question de repetition rigou- 
reuse de procedures, periodiquement revues et ameliorees, entre dans une 
certaine contradiction avec l’exigence d’adaptation necessaire pour atteindre 
l’agilite. 

Par ailleurs, la qualite du logiciel livre est un des objectifs majeurs des methodes 
agiles. 

Nous allons examiner comment sont prises en compte la qualite du produit et 
la qualite du processus projet. 

8.10.1 La qualite du produit dans les methodes agiles 

La definition de la qualite, rappelee au paragraphe 8.2, met 1’ accent sur la satis- 
faction des besoins implicites ou exprimes. Dans cette perspective la demarche 
iterative et participative des methodes agiles, avec des ajustements dynamiques 
aux evolutions des exigences des clients, est parmi les plus aptes a produire des 
systemes de qualite. 

De plus, les tests sont frequents, ils sont effectues a differents niveaux, et ils 
impliquent l’utilisateur qui doit en ecrire les jeux d’essai. Ces dispositions jouent 
largement en faveur de la qualite du produit 1 . 

L’ integration continue evite les surprises tardives, comme on peut en avoir 
parfois avec un cycle en V, lorsque plusieurs equipes ont longtemps travaille en 
parallele et que le moment est venu d’integrer le resultat de leurs travaux. 


8.10.2 La qualite du processus dans les methodes agiles 

Les methodes apparaissent discretes sur ce point, dans le sens ou l’accent n’est 
pas mis sur la formalisation des dispositions dans un Plan Qualite ou sur des 
audits qualite, meme si ces demiers sont evoques par DSDM. 

En revanche, le controle qualite est fort developpe, a travers les validations 
des utilisateurs, a chaque iteration de developpement. 

On peut done considerer que les methodes agiles ont une approche de la 
qualite qui repose davantage sur les personnes que sur des procedures. 


1. Pour une description des dispositions specifiques aux tests dans XP, voir par exemple 
J.L. Benard, L. Bossavit, R. Medina et D. Williams, Gestion de projet eXtreme Programming, 
Eyrolles, 2005, chapitre 4. 


DEUXIEME P ARTIE 


MISE EN CEUVRE, 
EXERCICES 
ET ETUDES DE CAS 


La deuxieme partie de cet ouvrage illustre les principes et les techniques du 
management d’un projet systeme d’information exposes dans la premiere partie. 

Le chapitre 9 est consacre a l’examen d’un projet, utilisant le diagnostic des 
risques. Cette analyse sert a prendre des decisions sur la strategic de projet et 
conduit a etablir un plan de management de projet. Deux cas sont proposes, tous 
deux issus de situations reelles. 

Le chapitre 10 permet d’appliquer sur le meme cas les differentes techniques 
d’estimation des charges : methode Delphi, repartition proportionnelle, modele 
Cocomo, evaluation analytique, methode des points fonctionnels. 

Le chapitre 11 propose une serie d’exercices de planification mettant en 
oeuvre les techniques du reseau des antecedents et du diagramme de Gantt. Ils 
illustrent l’utilisation pratique de ces outils. Tous les exercices sont corriges. 


a 


Partie II. Mise en oeuvre, exercices et etudes de cas 


Le chapitre 12 expose une demarche simplifiee de suivi de projet. 

Le chapitre 13 offre une mise en pratique des choix concemant la manage- 
ment d’equipe et la gestion des conflits. 

Le chapitre 14 propose un plan qualite associe a l’un des cas analyses au 
chapitre 9. 

La deuxieme partie s’acheve sur une illustration de l’utilisation d’un outil de 
planification et suivi de projet qui reprend le deroulement du cas Parking du 
chapitre 12. 
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La maitrise 
des risques 


9.1 LE CAS MECANO 

Le cas Mecano va permettre d’illustrer l’analyse de risque presentee au chapi- 
tre 6 (paragraphe 6.3), ainsi que l’etablissement d’une strategic de management 
de projet (paragraphe 6.4). 

9.1.1 Description de I’entreprise Mecano 

Mecano est une filiale d’un grand groupe automobile, specialisee dans la cons- 
truction de boites de vitesse. L’organigramme simplifie de la figure 9.1 comporte 
les principaux services, avec le nombre de personnes affectees a chacun. 


Direction 





Production | Qualite Maintenance Personnel 

Administration 
et finance 

| Informatique | 




1 850 pers. 50 pers. 400 pers. 20 pers. 30 pers. 30 pers. 


Figure 9.1 — Organigramme de I’entreprise Mecano. 
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Cette entreprise de 2 400 personnes est en permanence a la limite de ses 
capacites de production. Le directeur de l’entreprise et le chef du service infor- 
matique ont decide de mettre a disposition du service maintenance, charge de la 
reparation et de l’entretien des machines de fabrication, un outil informatique 
de maintenance assistee par ordinateur (MAO). Ce service passe un temps 
important a rechercher des informations, notamment sur les machines en panne 
(plans) et sur la disponibilite des pieces necessaires. II y a ainsi, en permanence, 
une trentaine de personnes a la recherche d’un plan. Le delai moyen d’interven- 
tion est de deux heures et la duree moyenne d’une intervention de trois heures. 


9.1.2 Description du projet Mecano 

Le futur systeme ne sera pas indispensable pour effectuer les taches concretes et 
immediates d’entretien et de reparation des machines. II comprend les fonctions 
suivantes : saisie des demandes d’intervention, planification des interventions, 
suivi des interventions en cours, solde d’une intervention. Les donnees concer- 
nees sont actuellement gerees sur papier, notamment la nomenclature des 
machines et les plans. 

On devra pouvoir reserver des pieces si elles sont disponibles en stock ou 
declencher automatiquement des commandes. Un certain nombre de statisti- 
ques sur les pannes seront foumies. Un module permettra de mettre en place une 
maintenance preventive. Un systeme de gestion de base de donnees objet pour- 
rait etre experiment^ a cette occasion. 

Les utilisateurs possibles sont divers, la plupart peu familiers des etapes de 
conception informatique (ouvriers de chaine de fabrication, chefs d’equipe. . . ) et 
de l’utilisation des moyens informatiques. 

Different^ services de l’usine sont touches par le projet : le service produc- 
tion, le service maintenance, le bureau des methodes (par exemple des statisti- 
ques pour expliquer des baisses de rendement de la production) et le service 
administrate et financier (statistiques pour calculer le cout d’une intervention). 

Apres avoir analyse le projet et elabore votre diagnostic du risque, choisissez 
un modele de cycle de vie et proposez une strategie de projet. 

9.1.3 Analyse du projet Mecano 

L’objectif du projet est d’augmenter la capacite reelle de production, en reduisant 
les temps de panne. 

L’observation d’une operation de maintenance fait apparaitre la pertinence du 
projet. La duree moyenne de traitement d’une panne est longue. Elle se construit 
en deux temps : d’abord la reaction a l’evenement panne, puis l’intervention 
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elle-meme. Or, le service maintenance represente plus de 20 % du personnel 
directement productif. On releve une perte sensible de temps et d’energie dans 
la recherche d’informations non disponibles ou eparpillees. On peut done consi- 
derer qu’en organisant la gestion et la circulation de l’information, on reduira 
sensiblement la longueur du cycle de traitement. 

Mais l’ambition du projet depasse le raccourcissement des circuits et la mise a 
disposition immediate d’ information. II vise egalement a developper une main- 
tenance preventive, basee sur l’analyse des incidents sur les machines. 

La legitimite du projet dans l’entreprise est garantie par l’engagement du directeur. 

Puisque l’objectif du projet est clair et pertinent et que son positionnement 
assure que des moyens y seront affectes, evaluons les risques qu’il presente. 


9.1.4 Profit de risque du projet Mecano 

Le profil de risque est donne a la figure 9.2. 

Le projet est de taille plutot importante. En effet les informations de base 
(nomenclatures machines, outillages...) ne sont pas encore structurees et font 
partie de l’etude. De plus, le degre d’automatisation pour la maintenance 
preventive est a priori eleve. La premiere exigence est imperative : on ne peut 
pas faire l’economie des informations peripheriques aux interventions. En revan- 
che, le perimetre de la prevention est a geometrie variable. 

La difficult^ technique provient de la nouveaute du systeme de gestion de 
base de donnees et la possible utilisation du multimedia pour gerer les plans. 

Le degre d’integration est eleve. L’ application devra etre interfacee avec la 
gestion des stocks et la gestion des achats, comme aussi probablement avec la base 
personnel, l’application controle de gestion, voire la planification de production 
si celle-ci devait intervenir dans une affectation de priorite. 

La configuration organisationnelle est tres large : le nombre d’utilisateurs 
concernes est de plusieurs centaines, et leur diversite recouvre la plus grande 
partie de l’usine. Quantite et variete generent un risque important. 

Le changement envisage est important. II porte sur deux points. D’une part, 
le futur systeme va modifier le role des ouvriers de production et de maintenance 
lors du constat d’une panne. La transparence introduite par un suivi automatise 
va diminuer d’eventuelles « zones d’ incertitude 1 ». Ceci risque de provoquer une 
resistance ou un detoumement dans l’utilisation du systeme. Si ce dernier n’est 


1. Selon le concept developpe par Michel Crozier dans L’Acteur et le systeme, Seuil, 1977. 
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pas un passage oblige pour effectuer les reparations, il faudra amener les futurs 
acteurs a l’utiliser et a l’alimenter correctement. En effet, la qualite des informa- 
tions de gestion que Ton pourra obtenir en sous-produit depend de l’exactitude 
et la completude des informations operationnelles. 

D’ autre part, tout le volet maintenance preventive est entierement nouveau. 
II y a done la un effort de conception tres important. 

L’equipe de projet ne presente a priori guere de risques, puisque Ton s’appuie 
sur des ressources internes. La seule interrogation porte sur les competences 
autour des nouvelles techniques : faut-il miser sur la formation ou s’appuyer sur 
une ressource externe ? 


Nature du risque 

Degre du risque pour le projet 
0 12 3 4 

Taille du projet 


Difficult^ technique 

Degre d’ integration 

Configuration organisationnelle 

Changement 

Instability de l’equipe de projet 


Figure 9.2 — Profil de risque du projet Mecano. 


9.1.5 Determination de la strategie de projet du projet Mecano 

Examinons tout d’abord les risques les plus importants et voyons s’il est possible 
de les reduire. 

La configuration organisationnelle peut representer une pesanteur dans la 
conduite du projet : il faut s’arranger pour decouper le projet en modules, qui 
chacun ne touchera qu’un nombre limite d’entites. En effet, le coeur du systeme 
concerne les services production et maintenance, les autres services sont utilisa- 
teurs des donnees produites. Il faudra neanmoins s’appuyer sur des utilisateurs 
delegues. Il serait souhaitable de trouver dans le service production ou le service 
maintenance un cadre ayant une bonne connaissance de l’usine, qui puisse etre 
detache sur le projet pour participer a la conception generale. Ce cadre devrait 
etre convaincu de l’utilite du projet pour s’en faire ensuite l’avocat aupres de 
ses pairs. 
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Ensuite, la gestion du changement doit etre prise serieusement en compte. 
On va done retenir une approche iterative, basee sur des cycles comprenant 
Elaboration d’un prototype suivie de tests par les utilisateurs. Les utilisateurs 
finaux etant trop nombreux pour etre tous associes directement au projet, on 
peut constituer un groupe temoin d’une vingtaine de personnes. Celles-ci, sur la 
base du volontariat, seront prises dans les deux services cles : maintenance et 
production. Les temps d’experimentation seront de l’ordre d’une ou deux semai- 
nes, les suggestions etant ensuite prises en compte apres une synthese. 

II est souhaitable qu’au terme d’une etape de conception generale, on ait deter- 
mine, comme dans le cycle XP, un nombre limite de cycles de livraison pouvant 
faire l’objet d’une mise en oeuvre incrementale. L’apprentissage des nouvelles 
technologies (objet et multimedia) doit commencer des le debut du projet. 

On peut done proposer le decoupage structurel suivant : 

• module 1 : gestion administrative d’une intervention ; 

• module 2 : gestion des donnees techniques (nomenclatures et plans) ; 

• module 3 : statistiques. 

Le module maintenance preventive doit s’appuyer sur des resultats statisti- 
ques, il est done souhaitable de differer son developpement. II fera partie d’une 
deuxieme version de 1’ application. 

Cela nous donne l’ebauche de plan de la figure 9.3. 



Figure 9.3 — Plan de projet du projet Mecano. 
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La phase d’exploration des besoins inclut Elaboration de deux prototypes, 
dont l’objectif est double. Elle offre aux commanditaires une premiere concreti- 
sation du futur systeme sur laquelle ils peuvent se prononcer. Elle permet que les 
developpeurs prennent en main des technologies avec lesquelles ils sont peu 
familiers. Ensuite, on retient trois iterations de livraison, chacune aboutissant a 
un module qui peut deja etre mis en exploitation. Les iterations de livraison sont 
composees d’iterations de developpement, avec la participation active des utili- 
sateurs du groupe temoin. 

Pour reduire le delai, on peut commencer le developpement du module 2 
quand on a realise 70 % du module 1. Le module 3 peut demarrer quand on a 
realise 50 % du module 2. 


9.2 LE CAS KALIZEAU 


Le cas Kalizeau va permettre d’illustrer l’analyse des parties prenantes, l’identifi- 
cation des alternatives, le decoupage structurel, l’analyse de risque et le reperage 
des types de reponse. 

9.2.1 Presentation du projet Kalizeau 

L’etat de Valbourg 1 , nouvellement integre dans l’Europe, vient de terminer un 
schema directeur qui definit les principes de gestion de l’etat ecologique des 
cours d’eau situes sur son territoire. En particulier, pour s’aligner sur les 
exigences europeennes, il a ete decide que la qualite des eaux devra etre mesu- 
ree systematiquement, lors de campagnes a intervalles reguliers. Pour chaque 
cours d’eau, on a selectionne des tronqons — points de recueil — sur lesquels se 
feront les prelevements. L’analyse des echantillons recueillis permettront de 
connaitre : 

1 . la composition chimique de l’eau ; 

2. la quantite et l’etat de sante des poissons recueillis, excellents indicateurs 
de la qualite de l’eau. 

Pour mettre en oeuvre ce schema directeur, il est necessaire de construire un 
systeme d’information permettant de gerer les informations issues des preleve- 
ments. Le projet Kalizeau a done ete lance. 


1. Ce cas, lointainement inspire d’un projet reel, a ete largement remanie a des fins pedagogiques. 
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Les fiches suivantes sont donnees a titre indicatif dans l’annexe du schema 
directeur. 



Figure 9.4 

9.2.2 Enonce de /'analyse des parties prenantes du cas Kalizeau 

Le projet est mene sous la responsabilite du service Qualite au sein du ministere du 
Developpement Durable (MDD). Deux responsables ont ete nommes, M me Olga, 
chimiste, et M. Bernard, biologiste. Le Ministere de la Peche est egalement impli- 
que, en la personne de M. Pedro. La maitrise d’oeuvre est confiee a la Direction 
informatique du MDD, placee sous la responsabilite de M. Blake. Les differents 
avis ont ete recueillis. 

M me Olga : « J’attendais depuis longtemps que l’on s’occupe de la qualite des 
eaux. Le projet Kalizeau va nous permettre, par la gestion organisee des informations, 
de vraiment progresses car nous saurons exactement ou nous en sommes. » 
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M. Bernard : « C’est un projet qui rentre tout a fait dans les preoccupations 
de notre Ministere. II faudra concevoir un systeme techniquement a la hauteur. 
On ne doit pas etre a la traine. Notamment, toutes les informations seront trans- 
mises par voie electronique, directement par les laboratoires d’ analyse charges 
des prelevements. » 

M. Pedro : « Ce projet va permettre a notre beau pays de developper 
une activite touristique autour des zones aquatiques. L’ Association des 
Pecheurs en Valbourg (APV) avait contacte mes services, a plusieurs reprises, 
pour me signaler des problemes sanitaires touchant certaines especes. Bon, eux 
ils sont partants, mais tout n’est pas aussi simple. Le syndicat des entreprises 
chimiques (SEC), nombreuses dans notre pays, s’est manifeste. II faudra faire 
tres attention aux donnees que l’on publiera, pour que cela ne fasse pas trop 
de vagues. » 

M. Blake : « C’est un projet interessant, cela nous permettra de mettre en 
oeuvre les technologies internet. Mais mes equipes sont encore pour beaucoup 
dediees aux systemes anciens. II va falloir que je monte un plan de formation 
solide pour mettre a niveau mes developpeurs. Comme je ne suis la que depuis 
Pete, je n’ai pas droit a l’erreur ! » 

Faire l’analyse de chacune des parties prenantes, en analysant : 

• ses relations avec les autres acteurs ; 

• ce qu’il/elle peut gagner ou perdre avec le projet (enjeux) ; 

• ses possibility d’action sur le projet ; 

• sa strategic probable. 

9.2.3 Corrige de /' analyse des parties prenantes du cas Kalizeau 

Le tableau de la figure 9.5 resume la position des principales parties prenantes. 


9.2 A Enonce de la structure de decoupage de projet Kalizeau 

En premiere approche, on a identifie les processus suivants : 

• Gestion des donnees sur l’empoissonnement. 

• Gestion des analyses de l’eau. 

• Etude des evolutions. 

• Mise a disposition des informations. 
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On prevoit quatre referentiels differents pour gerer les informations perma- 
nentes de Kalizeau. II s’agit des informations sur les cours d’eau, sur les points de 
recueil, sur les composants chimiques de l’eau et sur les categories de poissons. 

On envisage le decoupage en phases suivant : 

• Analyse globale 

• Conception technique et elaboration d’un prototype de saisie des preleve- 
ments 

• Developpement modulaire 

• Mise en oeuvre en deux temps, d’abord au MDD et dans un laboratoire 
pilote, puis generalisation a l’ensemble des laboratoires concemes. 

Proposer deux structures de decoupage de projet, selon que l’on privilegie le 
decoupage structurel ou le decoupage temporel. 

9 . 2.5 Corrige de la structure de decoupage du projet Kalizeau 

Le decoupage selon l’axe composant se presente comme a la figure 9.6. 



Figure 9.6 — Decoupage du projet Kalizeau selon I’axe composant. 


Le decoupage selon l’axe cycle de vie se presente comme a la figure 9.7. 
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Figure 9.7 — Decoupage du projet Kalizeau selon I’axe cycle de vie. 


9 . 2.6 Enonce de /' analyse de risque du projet Kalizeau 

On souhaite mettre en oeuvre le systeme Kalizeau d’ici un an. L’environnement 
technique retenu utilisera au maximum les standards du marche : protocole de 
reseau TCP/IP, serveur sous NT, base de donnees Oracle, langages de program- 
mation Visual Basic et Java. Selon les estimations effectuees, la charge de travail 
totale prevue est de 500 jours-personne. 

Les bases de donnees CoursEau et PointsRecueil sont gerees sur un serveur au 
niveau national. Les referentiels des Poissons et des Composants chimiques sont 
mis a disposition sous forme electronique par les instances europeennes ; la 
structure et le contenu sont stables, et si jamais des evolutions devaient apparai- 
tre (nouveau composant chimique ou nouveau poisson), la Communaute euro- 
peenne mettra un nouveau contenu a disposition. Le recapitulatif de chaque 
campagne est foumi, sous forme electronique, au Ministere de la Peche et a la 
Communaute europeenne. 
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Rappelons que les responsabilites de conduite du projet ont ete reparties 
comme suit. 

Le projet est mene sous la responsabilite du Service Qualite au sein du 
ministere du Developpement Durable (MDD), en liaison avec le ministere 
de la Peche. Deux responsables ont ete nommes par le MDD, Mme Olga, 
chimiste, et M. Bernard, biologiste, qui ont chacun un point de vue sur le 
projet. De plus, la vision du ministere de la Peche est plus politique que celle 
du MDD. Un representant des laboratoires d’analyse fait egalement partie du 
Comite de pilotage. 

La maitrise d’oeuvre est confiee a la Direction Informatique du MDD, placee 
sous la responsabilite de M. Blake. Les competences techniques de la Direction 
Informatique relevent en grande partie des systemes informatiques de type 
AS400, et peu sont familiers des technologies internet. C’est pourquoi le deve- 
loppement sera sous-traite a une SSII. En revanche, plusieurs assistants a 
maitrise d’ouvrage ont une bonne connaissance des metiers. La saisie des prele- 
vements se fera directement dans les laboratoires partenaires (une dizaine). II 
faudra prevoir une formation sur la partie precise de la saisie des resultats, car 
leur familiarite avec internet est limitee. 

Faire l’analyse de risques et dresser le profil du projet. 

9.2.7 Corrige de /' analyse de risque du projet Kalizeau 

L’analyse, basee sur une grille inspiree de celle de l’annexe C, se presente ainsi. 

Taille du projet = 2 


Critere 

Degre 

Metrique 


Duree 

1 

=< 6 mois 


2 

=<18 mois 

2 

3 

=< 30 mois 


4 

> 30 mois 


Charge 

1 

=< 20 mois-personne 


2 

=< 120 mois-personne 

2 

3 

=< 300 mois-personne 


4 

> 300 mois-personne 




Difficulty technique = 1 


Critere 

Degre 

Metrique 


Experience du marche 
sur 1’ architecture ciblee 

1 

Plus de 200 references 

1 

2 

Plus de 100 references 


3 

Plus de 50 references 


4 

Moins de 10 references 


Experience du marche 
sur le langage 
de programmation 

1 

Plus de 200 references 

1 

2 

Plus de 100 references 


3 

Plus de 50 references 


4 

Moins de 10 references 


Experience du marche 
sur le SGBD 

1 

Plus de 200 references 

1 

2 

Plus de 100 references 


3 

Plus de 50 references 


4 

Moins de 10 references 


Contrainte 
de performance 

1 

Normale 

1 

2 

Un peu elevee 


3 

Elevee 


4 

Tres elevee 



Degre d’integration =1,5 


Critere 

Degre 

Metrique 


Nombre de flux (type) 
inter applicatifs 

1 

=< 1 


2 

=< 5 

2 

3 

=< 10 


4 

> 10 


Nombre d’ applications 
connexes en chantier 

1 

Aucune 

1 

2 

= 1 


3 

= 2 


4 

>2 



Configuration organisationnelle = 4 


Critere 

Degre 

Metrique 


Nombre de personnes 
(de point de vue 
different) representant 
la maitrise d’ouvrage 

1 

= 1 


2 

= 2 


3 

= 3 


4 

>3 

4 

Nomination 
d’un promoteur 

1 

Nomine, implique, legitime 


2 

Nomme, implique 


3 

Nomme 


4 

Pas de promoteur 

4 

Appui de la Direction 
generale 

1 

Suivi par la DG 


2 

DG informee 


3 

Pas d’ implication de la DG, 
mais une seule MOA 


4 

Pas d’ implication de la DG 
et plusieurs MOA 

4 


Changement = 2,75 


Critere 

Degre 

Metrique 


Degre d’evolution 
organisationnelle 

1 

Pas d’ecart 


2 

Ecart faible 

2 

3 

Ecart moyen 


4 

Ecart fort 


Degre d’evolution 
fonctionnelle 

1 

Pas d’ecart 


2 

Ecart faible 


3 

Ecart moyen 

3 

4 

Ecart fort 



Critere 

Degre 

Metrique 


Degre devolution 
technique 

1 

Pas d’ ecart 


2 

Ecart faible 


3 

Ecart moyen 

3 

4 

Ecart fort 


Nombre de sites 
concemes 

1 

1 


2 

Moins de 10 


3 

Moins de 50 

3 

4 

Plus de 50 



Equipe = 1,3 


Critere 

Degre 

Metrique 


Competences 

techniques 

1 

Bonnes 

1 

2 

Moyennes 


3 

Faibles 


4 

Tres faibles 


Competences 

fonctionnelles 

1 

Bonnes 

1 

2 

Moyennes 


3 

Faibles 


4 

Tres faibles 


Image du projet 

1 

Tres valorisante 


2 

Valorisante 

2 

3 

Moyennement valorisante 


4 

Faiblement valorisante 



Le profil du projet peut etre ainsi visualise comme a la figure 9.8. 


a 


9 . La maltrise des risques 



9.2.8 Enonce des reponses aux risques du projet Kalizeau 

Apres analyse des risques, on a conclu que le projet Kalizeau doit faire face a une 
menace de depassement de delai pour les raisons suivantes. On pourra rencon- 
trer des difficultes pour faire converger les maitres d’ouvrage sur les fonctionna- 
lites necessaires. Les operationnels du MDD manifestent des inquietudes face a 
la future gestion des campagnes. Le manque de technicite des developpeurs du 
MDD pourra poser probleme, dans la mesure ou Ton a finalement decide de 
conserver en interne le developpement de la mise a disposition des informations. 

Determiner a quel type de reponse au risque se rattache chacune des mesures 
ci-dessous, en considerant que les mesures sont independantes entre elles. 

1 . Acheter le systeme propose par la communaute europeenne qui comporte les 
fonctionnalites de base. 

2. Negocier un delai supplemental d’un mois. 

3. Proposer d’elaborer l’expression des besoins sous forme d’une session JRP. 

4. Obtenir que le Ministere de la Peche exprime par ecrit ses exigences. 

5. Attendre que les MOA tombent d’accord. 

6. Creer une cellule de preparation au changement. 

7. Embaucher un specialiste Java et adopter un modele en W. 

8. Obtenir la nomination du Directeur du Service Qualite comme promoteur 
du projet. 

9. Si les fonctionnalites ne sont pas validees au 15 novembre, demander une 
reunion d’urgence du Comite de pilotage. 

10. Adopter une approche de developpement de l’application par version. 
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9.2.9 Corrige des reponses aux risques du projet Kalizeau 

La premiere mesure peut etre envisagee de deux fagons. On peut considerer 
qu’acheter un systeme existant va faire disparaitre le probleme de la determina- 
tion des besoins. II s’agit done d’un evitement. Si toutefois, on envisage d’enri- 
chir les fonctionnalites de base, il s’agit d’une attenuation. 

La deuxieme mesure est une acceptation active si Ton ne modifie pas 
l’echeancier et que le delai supplementaire est garde comme un tampon de 
reserve, utilise uniquement si on depasse la date de fin planifiee. Si, au contraire, 
on refait la planification et que Ton recule la date de fin visee d’un mois, il s’agit 
d’une attenuation, puisque Ton a introduit des marges dans l’ensemble du projet. 
La premiere disposition est celle qui est recommandee par la methode de la 
chaine critique (cf. § 4.6.2). 

Le travail en session sur les besoins, qui est planifie dans la troisieme mesure, 
devrait permettre, dans la mesure ou il n’y a pas d’antagonisme majeur entre les 
decideurs, d’attenuer voire d’eviter le risque. 

La quatrieme disposition correspond a un transfert du risque lie a l’expression 
des exigences provenant du Ministere de la Peche. Celles-ci ne pourront etre 
prises en compte que dans la mesure ou elles sont formalisees. 

Attendre qu’un consensus se fasse entre les decideurs correspond a une accep- 
tation passive. 

La creation d’une cellule de preparation au changement peut etre plus ou 
moins efficace. Selon les esperances que Ton a, il s’agit d’un evitement si l’on 
pense que le risque va disparaitre, ou d’une attenuation s’il semble que le risque 
n’a pas disparu. 

La septieme mesure devrait permettre de former les developpeurs, grace a 
l’accompagnement d’un specialiste et la construction d’un prototype. Selon la 
confiance que Ton a dans la capacite et la rapidite d’apprentissage des deve- 
loppeurs, il s’agit d’un evitement ou d’une attenuation. 

Si le Directeur du Service Qualite est nomme promoteur du projet, il aura 
une responsabilite particuliere dans le projet, ce qui attenuera les risques de non 
convergence sur les fonctions du futur systeme. 

La neuvieme mesure ne sera mise en oeuvre que si l’on constate 1’ absence de 
validation, il s’agit done d’une reponse conditionnelle. 

La demiere mesure qui s’inscrit dans une perspective iterative, avec une 
implementation a chaque iteration de livraison, devrait permettre d’attenuer le 
risque, aussi bien en ce qui concerne les besoins qu’en ce qui concerne la mise a 
niveau des developpeurs. 
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La pratique de Pestimation 
des charges 


10.1 LE CAS PARKING 

Nous allons estimer la charge du projet decrit ci-dessous (paragraphe 10.1.1) et 
utiliser pour ce faire les differentes methodes d’estimation. 

Nous simulerons d’abord la methode Delphi pour confronter le jugement des 
experts, en supposant les experiences indiquees ci-apres (paragraphe 10.1.2). 

Puis, nous utiliserons la methode de repartition proportionnelle du cycle de 
developpement classique. 

Nous appliquerons le modele Cocomo en prenant une valeur de la taille du 
logiciel de 2 400 lignes. 

Nous estimerons la charge de realisation par la methode devaluation analytique 
en nous basant sur l’identification des programmes, les ratios et poids standard 
donnes ci-dessous (paragraphe 10.1.3). 

Nous utiliserons la methode des points fonctionnels en faisant des hypotheses 
sur les fonctionnalites. 

Nous illustrerons enfin la demarche generale d’estimation et nous terminerons 
en comparant les differentes estimations. 


10.1.1 Description du projet Parking 

Nous sommes sur le centre de production d’un constructeur automobile. Deux 
chames effectuent le montage. Les vehicules sont ensuite transports chez les 
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distributeurs par un service Livraison/logistique. Les employes sont repartis dans 
des batiments parfois eloignes les uns des autres. On veut gerer l’acces aux diffe- 
rents parkings. 

On definit, pour chaque parking, les batiments qui sont accessibles a partir de 
ce parking. L’ attribution des places de parking se fera en fonction du lieu d’affec- 
tation de l’employe. L’ attribution depend egalement de la marque du vehicule : 
certains parkings sont interdits aux vehicules de marques concurrentes. 

Les employes peuvent obtenir des autorisations exceptionnelles de parking, 
par exemple s’ils participent a une reunion dans un autre batiment que leur bati- 
ment habituel. 

L’organigramme simplifie du centre de production est donne a la figure 10.1. 
C’est le service Divers qui gerera l’attribution des parkings. 



Figure 10.1 — Organigramme du cas Parking. 


10,1.2 Bases d’ experiences des experts 

Supposons quatre experts A, B, C et D, ayant chacun sa base d’experiences 
constitute des projets precedemment menes. Certains projets ont ete menes en 
commun par plusieurs d’entre eux. Analysons d’abord les experiences. 

La base d’experiences de l’expert A comprend trois projets, nommes D04, 
K67 et RESA. 

Le projet D04 « Description des commandes de vehicules » traite de la prise 
de commande, avec les options et couleurs choisies. Un catalogue devait rensei- 
gner sur les choix autorises. Le projet a dure quatre mois, mais pendant deux 
mois et demi un concepteur et un stagiaire sont venus renforcer A. 


10. 1. Le cas Parkins 


0 


Le projet K67 « Gestion des concours » est un projet commun a plusieurs 
ecoles de gestion. Le systeme comprenait les fonctions suivantes : enregistrer 
toutes les inscriptions, puis les notes obtenues aux differentes epreuves ecrites, 
calculer la moyenne (avec des coefficients de pondera tion variables). Selon les 
ecoles, le systeme produisait : soit deux listes « admis a l’oral » et « refuses » ; 
soit trois listes « grands admissibles », « petits admissibles » et « refuses ». Les 
admissibles passent ensuite un entretien de motivation, les « petits admissibles » 
ayant en plus des oraux sur differentes matieres presentes a l’ecrit. Le systeme 
enregistrait les notes d’oral et produisait alors une liste definitive. Une ecole 
situee a Evry avait des regies particulierement subtiles qui n’ont pas facilite la 
tache. A a commence en septembre, avec deux autres concepteurs, pensant 
avoir fini fin janvier. Les deux autres concepteurs ont termine leur partie mi- 
decembre, mais A a du poursuivre jusqu’a fin fevrier. 

Le projet RES A « Gestion des reservations de chambres d’hotel » a permis a 
A de passer deux mois a La Clusaz, avec un de ses collegues, puisque le client 
etait le syndicat d’initiative de cette station. La reservation est faite de faqon 
centralisee par le syndicat pour tous les hotels de la station. De plus, A a travaille 
seul a Paris pendant trois mois. 

La base d’experiences de l’expert B comprend egalement trois projets : IA55, 
SCI8 et BIB1. 

Le projet IA55 « Gestion des vols de 1’INT-Airlines » a ete mene deux ans 
auparavant. Cette compagnie aerienne gere des parcours-types, identifies par des 
codes IATA (par exemple Paris-Varsovie). Un parcours-type, selon sa distance 
et la frequentation de la destination, peut etre effectue par un ou plusieurs types 
d’avion (par exemple Airbus A320). Chaque vol effectue par la Compagnie est 
caracterise par l’affectation d’un avion (repere par son numero d’immatricula- 
tion) a un parcours-type pour une date donnee. Le projet a permis de gerer 
l’ensemble de ces donnees. B a du developper des interfaces avec deux autres 
applications : la maintenance des avions et la base des aeroports dans le monde. 
B etait aide par une seconde personne sur ce projet qui a dure trois mois. 

Le projet SCI8 « Gestion des conferences scientifiques » avait pour objectif 
de faciliter l’organisation des conferences par une societe scientifique. Chaque 
conference est preparee par un comite d’organisation et un comite de 
programme, dont les presidents sont des adherents. Apres appel a communica- 
tion, des articles sont proposes par des chercheurs. Lorsqu’un article arrive, le 
president du comite de programme l’attribue a des lecteurs, choisis parmi les 
membres du comite de programme, qui lui donnent une note. Selon la barre 
fixee, les articles peuvent etre selectionnes, refuses ou faire l’objet d’une delibe- 
ration par le comite de programme. Le systeme apres enregistrement des notes 
directement par les jures sur un serveur minitel, produit les lettres de reponse. 
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B a mis cinq mois pour mettre en place ce nouveau systeme. La societe disposait 
deja d’un serveur utilise par ses adherents. 

Le projet BIB1 « Gestion des prets », destine a la bibliotheque de son 
ancienne ecole, a rappele a B de bons souvenirs. II pensait n’en avoir que pour 
trois mois. Cependant, les regies de gestion variaient selon le type d’emprun- 
teur : eleves en formation initiale, participants a des modules de formation 
continue, masteres, professeurs permanents, professeurs vacataires, professeurs 
invites ou sabbatiques, thesards. De plus il a fallu etablir une liaison avec la 
base de donnees livres. Ces deux elements ont fait qu’il y a finalement passe 
cinq mois. 

La base d’experiences de l’expert C comprend les projets APP et ASS8. 

Le projet APP « Gestion des approvisionnements » visait a faciliter le suivi 
des campagnes d’approvisionnement de DISTRINT. Periodiquement, l’entre- 
prise lance des campagnes d’approvisionnement ou de reapprovisionnement : 
enregistrement des commandes, suivi des receptions, rapprochement avec les 
factures. C avait developpe un petit systeme expert pour proposer un plan de 
reapprovisionnement pour les articles peu soumis aux modes, prenant en 
compte la saison et les consommations anterieures (d’un article et des articles 
de substitution). Le projet integrait un suivi des fournisseurs prenant en compte 
la qualite des marchandises livrees et revolution de leur prix. Le projet a dure 
un an. Apres une etude prealable de deux mois, il a ete rejoint par un collegue 
qui l’a aide a elaborer un prototype et a le faire evoluer vers le systeme finale- 
ment implante. 

Le projet ASS8 « Gestion des polices d’assurance automobile » couvrait les 
fonctions classiques d’une compagnie d’assurance : elaboration d’un devis, suivi 
d’une proposition fixant les termes du contrat ; transformation de la proposition 
en contrat apres le versement de la prime, emission periodique des quittances, 
elaboration d’avenants et resiliation. C y a travaille avec deux collegues pen- 
dant trois mois, puis a ete remplace par une equipe de quatre personnes pendant 
six mois. 

La base d’experiences de l’expert D comprend les projets K67, APP et ASS8. 

D a mene le projet K67 « Gestion des concours » jusqu’a mi-decembre, il y a 
fait la connaissance de l’expert A. 

D a rejoint l’expert C sur le projet APP « Gestion des approvisionnements » 
apres l’etude prealable. 

D a travaille les six demiers mois sur le projet ASS8 « Gestion des polices 
d’assurance automobile ». 
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10.13 Elements pour I' evaluation analytique 

Pour l’etape de realisation, nous avons identifie quatre lots homogenes et inde- 
pendants. 

1. Le lot Parking comprend un complement des bases de donnees batiment 
et personnel, avec l’affectation des salaries, ainsi qu’un complement de 
la base parking, avec les proximites et les interdictions liees aux marques. 
Ce lot est compose de 10 programmes temps reel de difficulte moyenne. 

2. Le lot Vehicule comprend le repertoire des marques et la description des 
vehicules. II est compose de 5 programmes temps reel de difficulte moyenne. 

3. Le lot Automation comprend les demandes d’autorisation habituelle et 
exceptionnelle. II est compose de 5 programmes temps reel difficiles. 

4. Le lot Edition comprend differentes listes croisees entre Vehicules, Salaries 
et Autorisations. II est compose de 10 programmes batch faciles. 

Chaque lot comprend quatre types de taches : elaboration d’un jeu d’essai, 
etude technique, programmation et test qualite. Apres elaboration des lots, on 
prevoit une tache d’integration. 

La methode devaluation analytique est basee sur des poids standard et des 
ratios. Les unites d’oeuvre sont les programmes, les ratios permettant d’estimer la 
charge des autres taches s’appliquent a la charge de programmation. 

La tache d’integration pese entre 10 % et 15 % de la charge de programma- 
tion des quatre lots. 

Les poids standard affectes aux differentes unites d’oeuvre et mesures en jours- 
personne sont donnes a la figure 10.2. 


Type de programme 

Facile 

Moyen 

Difficile 

Temps reel 

2 

3 

5 

Batch 

1,5 

2,5 

3,5 


Figure 10.2 — Poids standard pour revaluation analytique du cas Parking. 


Les ratios utilises sont donnes a la figure 10.3. 

On decide de faire quelques ajustements. Les tests du lot Parking devraient 
etre assez rapides, de meme que l’etude technique du lot Autorisation. On retire 
respectivement 3 et 2 points au ratio permettant d’obtenir leur charge. L’etude 
technique du lot Vehicule devrait etre plus difficile : on decide de raj outer 
3 points au ratio. 
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Type de tache 

% de la charge de programmation 

Jeu d’essai 

20 

Etude technique 

10 

Tests 

10 


Figure 10.3 — Ratios pour revaluation analytique du cas Parking. 

On convient d’elaborer un jeu d’essai unique pour les lots Vehicule et 
Autorisations. 


10.2 CORRIGE DU CAS PARKING AVEC LA METHODE DELPHI 

L’exercice peut etre realise en dormant a quatre personnes (ou quatre groupes) le 
role des experts. Chacun doit reconstituer, si necessaire, la charge des projets de 
reference. 

L’expertise de A s’appuie sur des projets dont la charge est comprise dans un 
intervalle [7 ; 13] mois-personne. En effet : 

D04 : 9 mois-personne ; 

K67 : 13 mois-personne ; 

RESA : 7 mois-personne. 

L’expertise de B s’appuie sur des projets dont la charge est comprise dans un 
intervalle [5 ; 6] mois-personne. En effet : 

IA55 : 6 mois-personne ; 

SC 18 : 5 mois-personne ; 

BIB1 : 5 mois-personne. 

L’expertise de C s’appuie sur des projets dont la charge est comprise dans un 
intervalle [22 ; 33] mois-personne. En effet : 

A PP : TL mois-personne ; 

ASS8 : 33 mois-personne. 

L’expertise de D s’appuie sur des projets dont la charge est comprise dans un 
intervalle [13 ; 33] mois-personne. 

II s’agit done pour chacun de comparer la representation qu’il se fait du 
domaine Parking avec les projets anterieurement menes. 
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On observe souvent que ceux qui ont des petits projets en reference (expert 
A ou expert B) donnent une premiere evaluation inferieure a celle de ceux qui 
ont connu des projets plus importants (expert C ou expert D). Ces demiers 
projettent sur le projet une richesse ou une complexity fonctionnelle qu’ils ont 
deja rencontree. 

Le premier tour peut donner des estimations allant parfois du simple au 
quadruple, par exemple 4 mois-personne pour certains et 16 mois-personne pour 
d’autres. En general, l’estimation se rapproche ensuite avec une concentration 
autour de 8 mois-personne. 


103 CORRIGE DU CAS PARKING AVEC LA METHODE DE REPARTITION 
PROPORTIONNELLE 

Nous allons estimer la charge de l’etude prealable (par approche parametrique 
simplifiee) et nous en deduirons celle du projet complet. 

Pour cela, il faut ebaucher le plan d’interviews necessaire pour mener l’etude 
et affecter des poids a chaque interview. Ces poids (entre 0,5 et 3 jours) ne sont 
pas des durees d’interview, mais comprennent le travail de modelisation, 
synthese et diagnostic qui sera fait avec la matiere recueillie. 

On peut proposer de rencontrer les personnes suivantes : 

• Le directeur donnera ses orientations et ses ambitions en ce qui concerne 
le futur systeme. Envisage-t-il de l’etendre aux visiteurs ? De le proposer a 
d’autres usines du groupe ? On affecte a cette interview un poids de 1 jour. 

• Le service Divers est le futur gestionnaire : on rencontrera les trois 
personnes. On affecte un poids de 1 jour a chacun. 

• Le responsable du personnel est a l’origine des regies de gestion, il nous 
renseignera sur la mobilite des employes... On affecte un poids de 2 jours 
a cette interview. 

• On rencontrera egalement un representant du service Logistique, le 
responsable des approvisionnements, ainsi qu’un cadre d’une des deux 
chaines de production. On affecte un poids de 0,5 jour a chacun. 

La charge de l’etape observation de l’etude prealable se repartit comme indi- 
que a la figure 10.4. 

La charge de l’etape observation (7,5 jours-personne) represente environ un 
tiers de la charge de l’etude prealable. On estime done celle-ci a : 

22 jours-personne. 
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Interview 

Poids 

Directeur 

1 

Service Divers 

3 

Responsable personnel 

2 

Logistique 

0,5 

Approvisionnements 

0,5 

Chaine de production 

0,5 

Total 

7,5 


Figure 10.4 — Charge de I'etape observation du cas Parking. 

Si Ton considere que la charge de l’etude prealable represente 10 % du total, 
on obtient : 

charge du projet = 220 jours-personne. 

Ces 1 1 mois-personne se repartissent d’apres les ratios de distribution dans le 
cycle de developpement. Le resultat est donne a la figure 10.5. 


Phase 

Charge 

Etude prealable 

22 jours-personne 

Etude detaillee 

65 jours-personne 

Etude technique 

3 jours-personne 

Realisation 

130 jours-personne 

Total 

220 jours-personne 


Figure 10.5 — Repartition de la charge globale du cas Parking. 


1 0.4 CORRIGE DU CAS PARKING AVEC LE MODELE COCOMO 

Supposons qu’un informaticien ait evalue la taille du logiciel a 4 000 lignes, dans 
un langage de 3 e generation. 

On applique la formule pour les petits projets : 

Charge = 2,4 x 4 1,05 
Charge = 2,4 x 4,28 
Charge = 10,3 mois-personne 
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10.5 CORRIGE DU CAS PARKING AVEC LA METHODE D EVALUATION 
ANALYTIQUE 

Nous appliquons, lot par lot, les poids standard de chaque type de programme, et 
nous appliquons a la charge de programmation ainsi obtenue les ratios des taches 
peripheriques. L’evaluation analytique, arrondie a la demi-joumee pres, figure 
dans le tableau de la figure 10.6. 

Cela nous donne la charge de l’etape de realisation, incluant les taches 
d’etude technique. Nous utilisons la methode de repartition proportionnelle 
pour extrapoler la charge du projet complet (figure 10.7). 

Nous obtenons : 10,6 mois-personne 


Lot 

Type de tache 

Nombre 

d’unites 

Poids standard 
ou ratio 

Charge 
estimee en 
jours-personne 

Parking 

Programme en 
temps reel moyen 

10 

3 jours-personne 

30 


Etude technique 


10% 

3 


Jeu essai 


20% 

6 


Tests 


7% 

2 

Total lot Parking 

41 j/p 

Vehicule 

Programme en 
temps reel moyen 

5 

3 jours-personne 

15 


Etude technique 


13 % 

2 


Tests 


10% 

1,5 

Total lot Vehicule 

18,5 j/p 

Autorisation 

Programme en 
temps reel difficile 

5 

5 jours-personne 

25 


Etude technique 


8% 

2 


Jeu essai 


20% 

8 


Tests 


10% 

2,5 

Total lot Autorisation 

37,5 j/p 


Figure 10.6 — Evaluation analytique du cas Parkins. 
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Edition 

Programme batch 
facile 

10 

1,5 jours-per- 
sonne 

15 


Etude technique 


10% 

1,5 


Jeu essai 


20% 

3 


Tests 


10% 

1,5 

Total lot Edition 

21 j/ P 

Total programmation 

85 j/p 

Integration 




10 

TOTAL 




128 j/p 


Figure 10.6 — Evaluation analytique du cas Parking. (Suite) 


Etape 

Regie de calcul 

Charge 

Charge realisation 


128 jours-personne 

Charge etude detaillee 

La moitie de la charge de realisa- 
tion 

64 jours-personne 

Charge etude prealable 

Entre la moitie et le tiers de la 
charge d’ etude detaillee : on 
prend le tiers. 

21 jours-personne 

Total 


213 jours-personne, 
soit 10,6 mois-per- 
sonne 


Figure 10.7 — Extrapolation de la charge globale du cas Parking. 


10.6 CORRIGE DU CAS PARKING AVEC LA METHODE DES POINTS 
FONCTIONNELS 

La demarche consiste a identifier et denombrer tous les composants fonctionnels 
du futur systeme, en les classant par type d’unite d’ oeuvre et degre de complexite. 
Pour cela, nous ferons certaines hypotheses sur le futur systeme, que nous expli- 
citerons. 

Nous commengons par structurer rapidement les donnees, puis nous ferons 
une projection des differents traitements, afin de remplir les deux colonnes 
manquantes du tableau standard de la figure 10.8. 
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Entite 

Complexite 

Nombre de composants 

Poids 

Nombre de points 
de fonction brut 

GDI 

Faible 


7 



Moyenne 


10 



Elevee 


15 


GDE 

Faible 


5 



Moyenne 


7 



Elevee 


10 


ENT 

Faible 


3 



Moyenne 


4 



Elevee 


6 


SOR 

Faible 


4 



Moyenne 


5 



Elevee 


7 


INT 

Faible 


3 



Moyenne 


4 



Elevee 


6 


Total 






Figure 10.8 — Tableau de denombrement des points de fonction. 

10.6.1 Denombrement des groupes de donnees referencees 

Pour identifier les groupes de donnees (GDI et GDE), nous elaborons un modele 
des donnees simplifie (figure 10.9). 

La gestion des parkings suppose que Ton connaisse les parkings utilisables et 
pour chacun d’eux les eventuels interdits. Les batiments et leur situation par 
rapport aux parkings doivent etre repertories. Pour pouvoir faire l’affectation, il faut 
connaitre la localisation habituelle de chaque employe proprietaire d’un vehicule. 

Pour les autorisations exceptionnelles, nous avons fait le choix de ne pas 
relier les demandes a un calendrier des reunions avec les salles correspondantes. 
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La pertinence d’une demande exceptionnelle reste done en dehors du systeme 
informatise. 

Enfin, on a choisi de ne pas suivre l’utilisation reelle de la place attribute. 
On suppose que : 

• chaque batiment est proche d’au moins un parking ; 

• pour toute marque, il y a au moins un parking accessible ; 

• un employe n’est base a un moment donne que dans un seul batiment ; 

• un seul proprietaire du vehicule est declare ; 

• un employe ne peut pas declarer plus de deux vehicules ; 

• le systeme propose une ou plusieurs affectations, s’appuyant sur les regies 
en vigueur ; 

• toute affectation doit etre confirmee manuellement. 



Figure 10.9 — Modele des donnees du cas Parking. 


Les groupes de donnees referencees sont : 

• employe ; 

• vehicule ; 

• batiment ; 
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• parking ; 

• marque ; 

• autorisation habituelle ; 

• autorisation exceptionnelle. 

Les groupes de donnees externes (GDE) sont ceux qui sont deja geres par 
d’autres domaines. II est clair que Ton n’a pas attendu la gestion des parkings 
pour constituer un referentiel employe : ce groupe de donnees est done externe. 

La question se pose pour les donnees bdtiment et parking : sont-elles deja 
gerees sous forme informatisee par le service Logistique ? Nous faisons ici l’hypo- 
these qu’elles le sont. 

On a done la repartition donnee a la figure 10.10. 


GDE 

GDI 

employe 

vehicule 

batiment 

marque 

parking 

autorisation habituelle 


autorisation exceptionnelle 


Figure 10.10 — GDR du cas Parking. 


A part employe, tous les groupes de donnees, internes ou externes, sont de 
faible complexite. En effet, n’ayant pas de sous-type, ils n’ont qu’un seul sous- 
ensemble logique ; de plus le nombre de leurs proprietes elementaires ne devrait 
pas depasser 110. 

On fait l’hypothese vraisemblable que le groupe employe est d’une complexite 
moyenne. 

On obtient done pour les donnees le denombrement de la figure 10.1 1. 


Type 

Complexite 

Nombre 

GDI 

Faible 

4 

GDE 

Faible 

Moyenne 

2 

1 


Figure 10.1 1 — Denombrement des donnees du cas Parking. 
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10,6,2 Denombrement des entrees 

Pour reperer les entrees de l’application (ENT), on s’appuie sur les donnees 
internes. Tous les GDI doivent faire l’objet d’au moins une entree. 

On peut done dresser la liste suivante : 

• un ecran de saisie des marques, avec le cas echeant les parkings interdits ; 

• un ecran de saisie des vehicules, avec le proprietaire et la marque ; 

• un ecran d’ affectation d’une autorisation habituelle ; 

• un ecran de saisie d’une demande exceptionnelle ; 

• un ecran d’affectation d’une autorisation exceptionnelle. 

La complexite de ces entrees est donnee a la figure 10.12. 


Libelle de l’entree 
(ENT) 

Donnees utilisees 
(GDI ou GDE) 

Nombre de donnees 
elementaires (DE) 

Complexite 

Saisie des marques 

marque 

parking 

moins de 15 

moyenne 

Saisie des vehicules 

vehicule 

employe 

marque 

moins de 5 

moyenne 

Autorisation habituelle 

autorisation habituelle 

batiment 

parking 

moins de 5 

moyenne 

Demande 

exceptionnelle 

employe 

vehicule 

batiment 

moins de 5 

moyenne 

Autorisation 

exceptionnelle 

autorisation 

exceptionnelle 

parking 

moins de 5 

moyenne 


Figure 10.12 — Denombrement des entrees du cas Parking. 


10.6.3 Denombrement des sorties 

Les sorties sont principalement des etats de gestion permettant d’evaluer la perti- 
nence des regies d’ attribution et de les faire eventuellement evoluer. II s’agit de 
statistiques sur l’occupation des parkings, les autorisations exceptionnelles... 
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II est difficile d’aller plus loin avant de mener l’etude. Par precaution, on 
compte 5 sorties, dont 3 de faible complexite et 2 de complexity moyenne 
(figure 10.13). 


Type 

Complexite 

Nombre 

SOR 

Faible 

3 


Moyenne 

2 


Figure 10.13 — Denombrement des sorties du cas Parking. 


10.6 A Denombrement des interrogations 

Chaque groupe de donnees interne doit pouvoir etre consulte. On prevoit au 
minimum les listes (ecran ou papier) suivantes : 

• vehicule ; 

• marque ; 

• parkings avec et sans interdiction ; 

• autorisation habituelle ; 

• autorisation exceptionnelle. 

II faut y ajouter un certain nombre de listes croisees, telles que : 

• vehicules d’une marque donnee ; 

• vehicules affectes a un parking donne ; 

• employes ayant regu des autorisations exceptionnelles ; 

• etc. 

On compte done une dizaine d’interrogations (INT), dont 2 de complexite 
moyenne et les autres de faible complexite (figure 10.14). 


Type 

Complexite 

Nombre 

INT 

Faible 

8 


Moyenne 

2 


Figure 10.14 — Denombrement des interrogations du cas Parking. 
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10.6.5 Estimation de la charge 

Le denombrement complet, conduisant au nombre de points de fonction brut, 
est donne a la figure 10.15. 


Entite 

Complexite 

Nombre 
de composants 

Poids 

Nombre de points 
de fonction brut 

GDI 

Faible 

4 

7 

28 

GDE 

Faible 

2 

5 

10 

Moyenne 

1 

7 

7 

ENT 

Moyenne 

5 

4 

20 

SOR 

Faible 

3 

4 

12 

Moyenne 

2 

5 

10 

INT 

Faible 

8 

3 

24 

Moyenne 

2 

4 

8 

Total 

119 


Figure 10.15 — Estimation complete du nombre de points de fonction du cas Parking. 


Nous ne faisons pas d’ajustement. La taille du logiciel est done de 119 points 
de fonction. En prenant une valeur moyenne de 2 jours par point de fonction, on 
obtient : 

charge du projet = 238 jours-personne 
soit 11,9 mois'personne. 


10.7 ENONCE DE LA DEMARCHE GENERALE D’ESTIMATION 

L’ application informatique du projet Kalizeau, dont l’enonce a ete donne au 
paragraphe 9.2, va faire l’objet d’une mise en oeuvre pilote. Dix personnes du 
ministere du Developpement Durable (MDD) sont concemees, ainsi que cinq 
personnes d’un laboratoire partenaire du projet. 

Un nouveau materiel va etre installe au MDD pour l’occasion, soit un serveur 
et des postes pour tous les acteurs du ministere participant a cette premiere mise 
en oeuvre. Le laboratoire prend en charge son propre equipement. L’ installation 
du materiel comprend la reception du materiel et une verification de son fonc- 
tionnement, ce qui prend environ un quart de joumee pour chaque poste. La 
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charge d’installation du serveur a donne lieu a diverses evaluations, obtenues par 
la methode Delphi. La valeur la plus frequemment indiquee se situe autour de 
1,5 jour, la plus basse etant de 0,5 jour et la plus elevee de 5,5 jours. 

La recette se fera sur un jeu d’essai compose de cinq cas d’utilisation. Chaque 
cas mobilisera deux personnes pendant un quart de journee. 

On prevoit de monter deux formations. La premiere concerne le MDD et le 
laboratoire, et presentera la saisie des prelevements. La seconde portera sur les 
interrogations et les sorties et ne s’adresse qu’au MDD. 

Le temps de preparation des formations, c’est-a-dire le choix du contenu et 
Elaboration du support, est evalue en se basant sur les resultats de l’estimation 
du projet par la methode des points de fonction. II est proportionnel au nombre 
d’entrees (ENT) pour la premiere et au nombre de sorties et d’interrogations 
(SOR et INT) pour la seconde. Chaque composant fonctionnel necessite soit 
0,5 jour, 1 jour ou 2 jours de travail de preparation du support de formation selon 
son degre de complexite. 

Le decompte en entites fonctionnelles est le suivant : 


Type 

composant 

Faible complexite 

Complexite 

moyenne 

Complexite 

elevee 

ENT 

3 

2 

2 

SOR 



2 

INT 



1 


Figure 10.16 — Denombrement des entites fonctionnelles du projet Kalizeau. 


La premiere formation devra durer une journee, la seconde durera une demi- 
journee. Compte tenu du nombre de postes dans la salle de formation, les 
sessions comprendront au maximum dix personnes. 

La charge de coordination s’eleve a 20 % de l’ensemble. 

Estimer la charge totale de la mise en oeuvre pilote. 
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La charge totale correspond a 28 jours-personnes, a repartir entre les differents 
acteurs et leurs competences, selon le tableau ci-dessous (figure 10.17). 
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Unite d’oeuvre 

Nombre 

Poids 

Charge en 
jour-pers. 

Installation des postes 

Poste 

10 

0,25 

2,5 

Installation du serveur 

Unique 

1 

2 

2 

Recette 

Cas d’ utilisation 

5 

0,5 

2,5 

Preparation formation 

Entrees simples 

3 

0,5 

1,5 

Entrees moyennes 

2 

1 

2 

Entrees complexes 

2 

2 

4 

Sorties et interrogations 
complexes 

3 

2 

6 

Animation formation 

l re formation 

2 

1 

2 

2 e formation 

1 

0,5 

0,5 

Sous-total 




23 

Coordination 



20% 

5 

TOTAL 

28 


Figure 10.17 — Estimation de la charge de mise en oeuvre pilote du projet Kalizeau. 


10.9 COMPARISON DES DIFFERENTES METHODES 

Le tableau de la figure 10.18 recapitule les estimations obtenues. Celles-ci ne 
comprennent ni les charges d’encadrement, ni les charges de recette, ni les char- 
ges de mise en oeuvre. 


Methode 

Charge du projet en mois-personne 

Delphi 

8 

Repartition proportionnelle 

11 

Cocomo 

10,3 

Evaluation analytique 

10,6 

Points fonctionnels 

11,9 


Figure 10.18 — Comparaison des differentes estimations du cas Parking. 


Plusieurs remarques s’imposent. 
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L’evaluation Delphi est la plus incertaine ; elle est fortement dependante des 
experiences de l’expert ; c’est souvent un compromis entre des comprehensions 
parfois eloignees de l’ambition du projet. II est bon que l’animateur de la confron- 
tation fasse expliciter les raisons du classement par rapport aux projets de reference. 

L’evaluation Cocomo recouvre essentiellement l’etape de realisation. En effet 
cette methode date d’une epoque ou la conception etait limitee. L’evaluation des 
charges ne la prenait en compte que pour une part tres reduite. II faut done 
comparer la valeur obtenue, 10,3 mois-personne, a celle provenant directement 
de l’estimation analytique avant extrapolation, e’est-a-dire 6,4 mois-personne. 

L’evaluation analytique est precise, mais elle oblige a determiner par type de 
programme le nombre previsible. II est interessant de comparer en fin de projet 
avec ce qui a ete reellement programme. Elle permet eventuellement d’ajuster le 
perimetre fonctionnel de l’application avant son developpement, si le delai vise 
est incompatible avec la charge estimee. 

La methode des points fonctionnels oblige a expliciter l’idee que l’on se fait 
du futur systeme. La demarche de denombrement des composants fonctionnels 
ne remplace pas les etapes de conception du systeme d’information. C’est une 
simple projection d’une solution vraisemblable. On dispose ainsi d’une ebauche 
dont le developpement correspondra a la charge estimee. Cela permet de dire : 
« Voila ce que je peux vous faire pour le prix annonce ! ». 

On pourra ainsi faire un denombrement a posteriori en fin de projet. II 
permettra de verifier si un eventuel ecart de charge correspond a une difference 
fonctionnelle. 
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L’application dcs techniques 
de planification des delais 


11.1 EXERCICE CONFERENCE 

II s’agit d’organiser une conference scientifique, avec appel a communications et 
recherche de partenaires et sponsors. 

Cette activite comprend les taches suivantes : 

II faut tout d’abord determiner le theme, ainsi que la cible visee. Ensuite, un 
premier groupe s’occupe des aspects scientifiques et du contenu de la conference, 
tandis qu’un deuxieme groupe recherche des partenaires et des sponsors. 

Apres la determination du budget et la selection des conferenciers, on peut 
constituer le programme et le diffuser, tout en preparant la logistique. 

Les taches du premier groupe comprennent : 

• la redaction d’un descriptif de la conference ; 

• la constitution d’un comite scientifique et d’un comite de programme ; 

• le choix d’une date et d’un lieu ; 

• la redaction et la diffusion des appels a communication ; 

• la reception des communications et l’envoi aux notateurs des le lendemain ; 

• la reception des notes, la selection des communications et la reponse aux 
auteurs. 
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Les taches du deuxieme groupe consistent a : 

• reperer les appuis potentiels ; 

• faire appel a des sponsors possibles et recueillir leurs reponses ; 

• prendre contact avec des partenaires, puis dresser un bilan des contacts ; 

• determiner le budget. 

Le reseau des antecedents donne a la figure 11.1 represente les contraintes 
d’enchainement. Les durees figurent dans les rectangles representant les taches. 
Trouvez la duree minimale de ce projet en respectant les types de liens. 


| Preparation de l’accueil : 2j 


- 7 n 

I Inscriptions : 30j I 

H- .0 j * 


Logistique : 5j | 


Envoi programme : 2j 


[Reponse aux propositions : 2j | 


| Selection des communications : lj | 


Constitution programme : 2j 

, t 

| Determination budget : lj | 


Reception des notes : 15j I I Recueil des reponses : lOj I I Bilan des contacts : lj I 

r 

Envoi aux notateurs : lOj | | Appel aux sponsors : 45j | | Contact partenaires : 30j | 



Determination theme et cible : lj | 


Figure 11.1 — Reseau des antecedents de I’exercice conference. 


7 1.2. Corrise de I’exercice Conference 
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11.2 CORRIGE DE L’EXERCICE CONFERENCE 


Le corrige est donne a la figure 11.2. Tous les liens sont de type fin-debut, sauf 
celui qui unit Reception communications et Envois aux notateurs qui est de type 
debut-debut, avec un retard d’un jour. On releve cinq retards et deux avances. 
La duree totale est de 122 jours, comme le montre le graphe ci-dessous, ou Ton a 
fait figurer les dates de debut et fin a cote de chaque tache, en supposant que le 
projet commence au temps 1. Elies doivent se lire ainsi, par exemple pour la 
tache Determination theme et cible : 1 

1 

La tache commence en debut du jour 1 et se termine en fin du jour 1. 

La tache Inscriptions est celle qui se termine en dernier. 


Preparation de 1’accueil : 2j 

r 

| Inscriptions : 30j~] ' 

+ io it 


| Logistique : 5j | & 


Envoi programme : 2j 


i — ; 1 

[Reponse aux propositions : 2j | yy 
| Selection des communications : lj | \ 


^ Constitution programme : 2j | ^ 
| Determination budget : lj | ^ 


Reception des notes : 15j \ ^ \ Recueil des responses : lOj | | Bilan des contacts : lj | ^ 

t , ^ f - lOj | + 4j 

Envoi aux notateurs : lOj | ^ | A ppel aux sponsors : 45j | 47 \ Contact partenaires : 30j | 32 


Reception communications : lOj I ^ i 7^ — — r~i . 

x : 1 52 Reperage appuis potentiels : lj 

t+30j - — - 



| Determination theme et cible : lj | ^ 


Figure 1 1 .2 — Corrige de I'exercice Conference. 
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113 EXERCICE PETIT DEJEUNER 

Vous vous preparez chaque matin un petit dejeuner comportant : une saucisse, 
deux oeufs mollets (que vous mettez directement dans l’eau ffoide), deux toasts 
et un verre de lait. Vous cherchez a reduire au minimum le temps de preparation. 
Pour cela, vous devez etablir une strategic d’ordonnancement de vos taches. Pour 
la representer, tracez un graphe representant l’enchamement des taches identi- 
fiees a la figure 1 1.3, sachant que : 

• vous etes seul pour tout faire ; 

• vous preparez a la cuisine, mais vous mangez dans la salle a manger ; 


N° tache 

Description de la tache 

Duree en secondes 

1 

Prendre verre, assiette et converts dans le buffet 

20 

2 

Poser les converts sur la table 

15 

3 

Prendre le pain dans le garde-manger 

10 

4 

Mettre deux tranches de pain dans le grille-pain 

5 

5 

Faire griller le pain 

140 

6 

Poser les toasts sur 1’ assiette 

5 

7 

Beurrer les toasts dans 1’ assiette 

15 

8 

Sortir les ceufs, le beurre et la saucisse du refrigerateur 

25 

9 

Mettre de l’eau dans la casserole 

10 

10 

Mettre les ceufs dans l’eau 

5 

11 

Faire cuire les ceufs 

170 

12 

Mettre les ceufs dans 1’ assiette 

20 

13 

Sortir le lait du refrigerateur 

10 

14 

Verser du lait dans le verre 

5 

15 

Poser le verre de lait sur la table 

10 

16 

Mettre la saucisse dans la poele 

5 

17 

Faire cuire la saucisse 

210 

18 

Poser la saucisse dans P assiette 

15 

19 

Poser l’assiette pleine sur la table 

10 

20 

Se mettre a table 

2 


Figure 1 1 .3 — Taches de I’exercice Petit dejeuner. 
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• n’ayant que vos deux mains, vous ne pouvez faire qu’une seule chose (tache) 
a la fois ; 

• vous disposez de quatre plaques de cuisson ; 

• vous devez intervenir sans attendre des que la cuisson est terminee ; 

• vous preferez beurrer vos toasts quand ils sont tres chauds. 


11.4 CORRIGE DE L’EXERCICE PETIT DEJEUNER 


L’ analyse du probleme fait apparaitre les points suivants. 

• On doit preparer quatre elements independants : saucisses, oeufs, pain et lait. 

• La seule possibility de parallelisme est celle des taches de cuisson. 

Les taches de cuisson sont celles qui prennent le plus de temps. 

La strategic d’ordonnancement sera done de commencer par la tache de cuis- 
son la plus longue. 

On obtient le graphe de la figure 1 1 .4, avec une duree minimale de 277 secondes. 


T8 : 

25s 

i 

T16 

:5s 


T9: 

10s 


1 ' 

T10 

:5s 

+ 

T3 : 

10s 


r 

T4 

: 5s 


Cuisson de la saucisse 


I Til • 170s I Cuisson des oeufs 


T 5 . ] 40s Cuisson du pain 


T9 :2s 

I 


l 

T7 : 15s 


| T1 : 20s >C T2 : 15s | -»- | T13 : 10s | -»> | T14 : 5s~~ | -»> | T15 : 


Figure 11.4 - Graphe de I’exercice Petit dejeuner. 


77 . L’application des techniques de planification des delais 


La sortie du pain du garde-manger (T5) ne peut etre faite pendant la cuisson 
des oeufs, sinon on ne peut terminer le pain avant la fin des oeufs. Cela oblige a 
remplir la casserole d’eau (T2) avant de commencer a cuire la saucisse. Sinon on 
ne pourrait finir les oeufs avant la fin de la cuisson de la saucisse. 


11.5 EXERCICE REVEIL 

Les freres Marx se preparent tous les jours pour partir rejoindre les studios selon 
un ordre desormais coutumier (figure 11.5). Tracez un graphe de type reseau des 
antecedents pour detecter d’eventuels inconvenients. Proposez, le cas echeant, 
des ameliorations. 


11.6 CORRIGE DE L’EXERCICE REVEIL 

A partir de la sonnerie du reveil de Groucho et jusqu’a leur depart de la maison, 
les preparatifs des trois freres peuvent etre representes comme a la figure 1 1.6. II 
n’y a que des liens de type fin-debut. Par simplification, nous n’avons pas fait 
apparaitre les parametres cles, mais uniquement les dates au plus tot et les temps 
d’attente de certains (en gras). Ces demiers correspondent a la marge. Le 
chemin critique correspond ici au chemin le plus long. C’est celui de Harpo. 

Hanalyse du reseau fait apparaitre les points suivants : 

• La duree totale depuis le reveil du premier jusqu’au depart est de 69 minutes : 
c’est le chemin le plus long. 

• Les chemins correspondant a chacun des trois freres sont de longueur 
inegale. Un chemin se compose d’une part des taches que chacun effectue 
et d’autre part de temps d’attente. Si Ton appelle temps utile la somme des 
taches d’un acteur, on obtient : 

- temps utile de Groucho : 44 minutes ; 

- temps utile de Harpo : 67 minutes ; 

- temps utile de Chico : 29 minutes. 

Les temps d’attente se repartissent de la fagon suivante : 

- Groucho : 24 minutes ; 

- Harpo : 0 minute et 2 minutes de sommeil supplementaire ; 

- Chico : 34 minutes et 6 minutes de sommeil supplementaire. 
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N°tache 

Description 

Duree en minutes 

Predecesseur 

Groucho 




G1 

Se reveille 

1 

- 

G2 

Reveille Harpo 

1 

G1 

G3 

Reveille Chico 

4 

G2 

G4 

Se coiffe 

1 

G3 

G5 

Prend une douche 

5 

G4, H2 

G6 

Choisit ses habits 

5 

G5 

G7 

S’habille 

2 

G6 

G8 

Va promener le singe 

5 

G7 

G9 

Prepare le repas du singe 

10 

G8 

G10 

Prend son petit dejeuner 

10 

G9, H6 

Gil 

Prend son chapeau 

1 

G10 

Harpo 




HI 

Bondit de son lit 

1 

G2 

H2 

Prend un bain 

9 

HI 

H3 

Fait de la gymnastique 

20 

H2 

H4 

S’habille 

10 

H3 

H5 

Fume une cigarette 

2 

H4 

H6 

Prepare le petit dejeuner 

5 

H5 

H7 

Prend son petit dejeuner 

10 

H6 

H8 

Prepare le pique-nique 

10 

H7 

Chico 




Cl 

S’etire 

2 

G3 

C2 

Se douche 

15 

Cl, G5 

C3 

Fait des assouplissements 

1 

C2 

C4 

S’habille 

5 

C3 

C5 

Prend son petit dejeuner 

5 

C4, H6 

C6 

Prend son echarpe 

1 

C5 


Figure 1 1 .5 — Taches de I'exercice Reveil. 
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9 mm 

18,32 


11 mm 

50,54 


Ainsi, Harpo est tres actif et n’attend jamais. A l’inverse, depuis son reveil, 
Chico passe plus de temps a attendre qu’a s’activer. Le chemin de Groucho se 
repartit en pres de deux tiers de temps actif pour plus d’un tiers de temps 
d’attente. 
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• La douche est une ressource partagee qui peut etre consideree comme un 
point de blocage, puisque Groucho et Chico se retrouvent tous deux en 
situation d’attente. 

• Le petit dejeuner est pris en commun, ce qui est une excellente chose. 
Mais on peut egalement considerer que c’est un point de blocage. En 
effet, Groucho et Chico attendent que Harpo ait fini de le preparer pour 
tout le monde. 

• Le pique-nique prepare par Harpo apres le petit dejeuner retarde le 
depart. 

Les inconvenients sont directement lies aux criteres utilises pour juger d’un 
« bon » reseau. En dehors des habitudes personnelles des trois freres, on peut 
faire deux suggestions. 

D’une part, les temps d’attente pourraient etre reduits ou transformes en 
temps de sommeil supplemental . 

D’ autre part, la duree totale de preparation, entre la sonnerie du reveil et le 
depart, pourrait elle-meme etre raccourcie. 

Pour cela, plusieurs moyens sont a notre disposition. 

Pour reduire le chemin critique, il faut essayer soit de reduire la duree de 
certaines de ses taches, soit de supprimer certaines taches ou de les transferer a 
d’autres. 

On peut ainsi suggerer a Harpo : 

• soit de s’abstenir de fumer ; 

• soit de preparer le pique-nique la veille ou bien de le confier a un de ses 
freres ; 

• soit de prendre une douche, ce qui devrait etre plus rapide qu’un bain. 

Pour reduire les temps d’attente, il faut travailler sur les points de blocage. La 
solution consiste soit a modifier certaines contraintes, soit a raj outer des ressour- 
ces. Ainsi, on peut imaginer : 

• que Groucho et Chico prennent successivement leur douche pendant que 
Harpo fait sa gymnastique, ce dernier ne se baignant qu’ensuite (interver- 
sion des taches H2 et H3 ) ; 

• l’amenagement d’une douche complementaire, ce qui supprime l’attente 
de Harpo ; Chico pourrait alors etre reveille apres la toilette de ce dernier ; 

• que le petit dejeuner soit prepare par Chico, qui a tout le temps apres 
s’etre habille. 
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Figure 1 1 .7 Graphe remanie de I’exercice Reveil. 


7 7 . 7 . Exercice Cursus scolaire 
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La premiere representation des taches d’un projet sous forme de graphe des 
antecedents permet ainsi de reflechir, pour eventuellement ajuster la definition 
des taches et leurs contraintes. 

Nous avons refait (figure 1 1.7) le graphe du reveil des trois freres. 

C’est un exemple de reseau remanie, sans ajout de ressource ni suppression de 
tache : 


• Chico est reveille plus tard ; 

• il prepare le pique-nique en attendant que Harpo ait fini de prendre son 
bain ; 

• il arrive a la table du petit dejeuner cinq minutes apres ses freres, mais 
heureusement il mange plus vite ou moins qu’eux ; 

• Harpo fait sa gymnastique avant de prendre son bain, ce qui evite a 
Groucho l’attente de la salle de bains ; 

• il est decharge du petit dejeuner qui est pris en charge par Groucho ; 

On a, sur une duree totale ramenee a 58 minutes, la repartition suivante. 

Le temps utile de Groucho est de 50 minutes ; il attend 8 minutes au depart. 

Le temps utile de Harpo est de 52 minutes ; il attend 4 minutes au depart et 
beneficie de 2 minutes de sommeil supplementaire. 

Le temps utile de Chico est de 39 minutes. Il attend la douche 2 minutes et 
profite de 1 7 minutes de sommeil supplementaire. 


11.7 EXERCICE CURSUS SCOLAIRE 

Pour obtenir son diplome, l’etudiant doit avoir suivi avec succes douze modules, 
d’une duree d’un semestre. Il peut organiser ses etudes librement, sous reserve des 
contraintes d’enchamement donnees a la figure 11.8. 

Tracez le graphe des antecedents. Quelle est la duree minimum des etudes ? 
Proposez, au moyen de diagrammes de Gantt, trois plans d’etudes : 

1 . en suivant les modules le plus tot possible ; 

2. en suivant les modules le plus tard possible ; 

3. en repartissant au mieux la charge de travail sur toute la duree des etudes. 
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Module 

Predecesseurs 

A : Comptabilite I 


B : Comptabilite II 

A 

C : Comptabilite analytique 

A 

D : Analyse financiere 

K, B 

E : Systeme d’information I 

C, B 

F : Systeme d’information II 

H 

G : Marketing I 

I 

H : Marketing II 

G 

I : Gestion de Production 

B, I 

I : Economic 


K : Gestion Ressource humaine 

I 

L : Strategie 

E, G 


Figure 1 1 .8 — Contraintes d'enchaTnement du cursus scolaire. 


11.8 CORRIGE DE L’EXERCICE CURSUS SCOLAIRE 

Le graphe des antecedents et les parametres du chemin critique sont donnes a la 
figure 11.9. 



Figure 1 1 .9 — Reseau de I’exercice Cursus scolaire. 


7 1.8. Corrige de I’exercice Cursus scolaire 




Le chemin critique est indique en gras : la duree minimum des etudes est de 
six semestres. 

Le scenario au plus tot est donne a la figure 1 1.10. La charge s’allege au bout 
d’un an et demi. 


Semestre 


1 


A 


2 


B 


3 


I 


J 


C E 


K 


D 


4 

G 


5 6 

H F 


L 


Figure 1 1 .10 — Diagramme de Gantt de I'exercice Cursus scolaire 
(scenario au plus tot). 


Le scenario au plus tard est donne a la figure 11.11. La charge s’alourdit la 
demiere annee. 


Semestre 


1 


A 


2 


J 


3 


4 


G 


C 


5 6 

H F 


E L 


K 


D 


Figure 1 1 .1 1 — Diagramme de Gantt de I'exercice Cursus scolaire 
(scenario au plus tard). 


Le scenario lisse est donne a la figure 11.12. La charge est uniformement 
repartie sur les trois annees. 


Semestre 


1 


A 


2 

B 


3 4 5 6 

I G H F 


J 


C E K L D 


Figure 1 1 .12 — Diagramme de Gantt de I'exercice Cursus scolaire 
(scenario lisse). 
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11.9 EXERCICE ECHEANCIER 

Soit le projet represente dans le tableau de la figure 1 1.13. 


Tache 

Duree en semaines 

Lien 

tl 

5 

fin tl - debut t3 

t2 

2 

fin t2 - debut t4, t5 

t3 

10 

fin t3 - debut t6, t8 

t4 

8 

fin t4 - debut t6 

t5 

10 

fin t5 - debut t7 

t6 

25 

fin t6 - debut tl 1 

t7 

4 

fin t7- debut til 

t8 

10 

fin t8 - debut t9, tlO, til 

t9 

2 

fin t9 - debut tl3 

tio 

1 

fin tlO - debut tl3 

til 

15 

debut til - debut tl2 
fin til - debut tl3 

tl2 

10 

fin tl2 - debut tl4 

tl3 

12 

fin tl3 - fin 

tl4 

30 

fin tl4 - fin 


Figure 11.13 — Enonce de I’exercice Echeancier. 


Calculez les parametres cles et faites-les figurer sur un graphe des antecedents. 
Pour chaque tache indiquez les dates de debut au plus tot et de fin au plus tot, de 
debut au plus tard et de fin au plus tard, ainsi que les marges. 

Determinez le chemin critique. 

Que devient le chemin critique avec la contrainte : 
t9 ne peut pas commencer avant t = 7 1 ? 

Proposez deux echeanciers sans date imposee, d’abord en planifiant au plus 
tot, puis au plus tard. Vous les representerez sur un diagramme de Gantt. 
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On dispose des ressources Rl, R2 et R3, ayant les contraintes suivantes : 

• Rl est absent entre les periodes 26 et 50. 

• R2 ne peut pas commencer avant la periode 8. 

• R3 travaille a 50 %. 

Etablissez un calendrier du projet que vous representerez avec un diagramme 
de Gantt. 

11.10 CORRIGE DE L’EXERCICE ECHEANCIER 

11.10.1 Graphe des antecedents et parametres des 

Le graphe est donne a la figure 11.14. Le chemin critique est indique en gras. 

Les parametres cles se lisent ainsi : par exemple, la tache t3 commence au 
plus tot en debut du jour 6 et finit au plus tot en fin du jour 15. 

Le lien debut-debut entre til et tl2 fait apparaitre deux marges sur la tache 
tl 1. En effet, dans le calcul des dates au plus tard, la tache tl3 permet de finir au 
plus tard en t = 68. 

Ceci permettrait que tl 1 commence au plus tard en t = 68 - 15 + 1 = 54- 

Mais si Ton considere la tache tl2, son debut au plus tard est egal a 41. Par conse- 
quent, tl 1 qui declenche tl2, doit s’aligner sur ce debut au plus tard. II en resulte que 
tl 1 ne peut pas commencer avant t = 41 , mais peut se terminer en t = 68. 

Cela signifie que Ton peut envisager un travail a temps partiel sur cette 
tache : la duree calculee sur les dates au plus tard l’autorise. 

La seconde consequence est que l’on a deux valeurs de marge : sur les dates de 
debut, la marge est nulle ; en revanche sur les dates de fin, elle est egale a 13. 

11.10.2 Graphe avec date imposee 

Le graphe modifie est donne a la figure 11.15. 

La date imposee sur t9 a des consequences sur : 

• les dates au plus tot de toutes les taches subsequentes ; 

• la date de fin de projet, puisque t f passe a 84 ; 

• toutes les dates au plus tard, done sur les marges. 

Le chemin critique du deuxieme reseau ne parcourt pas tout le graphe, du 
debut a la fin : il se situe uniquement entre t9 et la fin du projet. Les chemins 
critiques partiels sont frequents lorsque Ton impose des dates. En l’absence de 
date imposee, le chemin critique est toujours complet. 


77. L'application des techniques de planification des delais 


0 



Figure 11.14 — Graphe des antecedents de I’exercice Echeancier. 
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Figure 11.15 — Graphe des antecedents avec date imposee. 
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1 1.103 Calendrier du projet 

La planification au plus tot donne le planning de la figure 11.16. 




Periode 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

85 

86 

87 

88 

89 

90 

R1 

t!4 











R2 

t!3 

























Figure 1 1 .16 — Diagramme de Gantt avec planification au plus tot. 
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On planifie d’abord le chemin critique, que Ton affecte a la ressource R1 : tl, 
t3, t6, tl2 et tl4. 

On repart ensuite au debut et on place le plus tot possible les autres taches, 
que Ton affecte a une seconde ressource R2 : d’abord t2, t4 ; puis t5, t7 ; puis t8, 
t9, tlO ; apres une interruption de trois periodes, til qui doit imperativement 
commencer en 40 ; enfin tl3. 

La planification au plus tard donne le planning de la figure 11.17. 

Le chemin critique reste positionne au meme endroit. On commence a affec- 
ter les taches a R2 par la fin : d’abord tl3 ; puis tlO et t9, en utilisant leurs 
marges ; puis til qui doit commencer en t = 40 ; ensuite on place la sequence t8, 
t7 et t5 ; la tache t4 devant s’achever au plus tard en t = 15, on a une periode 
d’attente entre t4 et t5 ; on place enfin t2. 



Periode 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 

R1 

t6 
































tl2 
































tl4 

R2 

t8 



















til 







Figure 1 1.1 7 — Diagramme de Gantt avec chargement au plus tard. 
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Periode 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

85 

86 

87 

88 

89 

90 

R1 

tl4 











R2 






t9 
































tio 
































tl3 












Figure 1 1.17 — Diagramme de Gantt avec chargement au plus tard. (Suite) 


11*10 A Planification avec contraintes sur les ressources 

Le diagramme de Gantt est donne a la figure 1 1.18. II faut commencer immedia- 
tement les taches du chemin critique. On y affecte done R1 jusqu’a son depart 
en conge. Comme il laisse la tache t6 inachevee, on prefere la confier a R2 ainsi 
que la suite du chemin critique. 

R1 fait done tl et t3. R2 fait t6, tl2 et tl4- R2 fera t4 avant de commencer t6. 
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0 


31 32 33 34 35 36 37 38 39 40 


41 42 43 44 45 46 47 48 49 50 


51 52 53 54 55 56 57 58 59 60 


Periode 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

85 

86 

87 

88 

89 

90 

R1 

til 
































tl3 


















R2 

tl4 
























Figure 1 1.18 — Diagramme de Gantt avec contraintes sur les ressources. (Suite) 


On cherche a affecter a R3 des taches dont la marge soit au moins double de 
la duree : en effet, comme R3 ne travaille qu’a mi-temps, on considere que les 
taches qu’il effectue ont une duree calendaire double. 

Les taches eligibles sont : t2, t5, t7, t9 et tlO. On les place le plus tot possible 
en evitant les interruptions. 

Les taches restantes sont : til et tl3. Cette demiere est affectee a R1 ; til 
pose un probleme car elle doit imperativement demarrer en meme temps que 
tl2. On va done la partager entre : 

• R3 qui produit une charge de cinq periodes en dix periodes, entre 41 et 50. 

• R1 qui prend la suite a son retour de conge : on compte un jour supple- 
mental pour prendre connaissance du travail de R3. 
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11.11 EXERCICE RECETTE ALEATOIRE 

Soit a estimer la duree d’une recette de gateau au chocolat. Une incertitude pese 
sur la duree de la preparation. Elle provient de differents facteurs : la qualite du 
four, la disponibilite de certains outillages (batteur electrique, par exemple) et la 
rapidite des patissiers. 

Le tableau de la figure 11.19 donne la liste des taches, ainsi que les estima- 
tions optimiste, pessimiste et vraisemblable de chaque tache. 


Taches 

Vt 

tpes 

tvrai 

R1 

Faire fondre le beurre et le chocolat 

6 

9 

7,5 

R2 

Separer les ceufs en jaunes et blancs 

1 

4,5 

3 

R3 

Ajouter les jaunes au melange fondu et faire cuire 
2 minutes 

6 

8 

7 

R4 

Monter les blancs en neige 

2 

12 

5 

R5 

Retirer le melange du feu et incorporer les blancs 

2 

6 

3 

R6 

Faire cuire au four 

16 

22 

18 


Figure 11.19 — Taches de I'exercice Recette aleatoire. 


Tracez le graphe des antecedents, sans contrainte de ressource (main d’oeuvre). 
Calculez le risque, la duree probable, 1’ecart-type et la variance de chaque tache. 
Quel est le chemin critique Z 

Quelle est la duree estimee de preparation du gateau : 

• avec une probability de 95 % ? 

• avec une probability de 90 % ? 

Quelle est la probability que l’on termine en 37 minutes ? 

11.12 CORRIGE DE L’EXERCICE RECETTE ALEATOIRE 

Le reseau est donne a la figure 1 1 .20. 

Les parametres probabilistes sont donnes a la figure 1 1.21. 

La duree estimee des chemins est donnee a la figure 1 1.22. 
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Figure 1 1.20 — Reseau de I’exercice Recette aleatoire. 


Taches 

top, 

tpes 

tyrai 

risque 

tprob(') 

e(i) 

v(i) = e(i)2 

R1 

6 

9 

7,5 

0,33 

7,50 

1/2 

0,25 

R2 

1 

4,50 

3 

0,78 

2,92 

7/12 

0,34 

R3 

6 

8 

7 

0,25 

7,00 

1/3 

0,11 

R4 

2 

12 

5 

0,83 

5,67 

5/3 

2,78 

R5 

2 

6 

3 

0,67 

3,33 

2/3 

0,44 

R6 

16 

22 

18 

0,27 

18,33 

1 

1,00 


Figure 11.21 — Parametres probabilistes de I’exercice Recette aleatoire. 


Chemins 

D(est) 

V(est) 

E(est) 

R1R3R5R6 

36,17 

1,81 

1,34 

R2R3R5R6 

31,58 

1,90 

1,38 

R2R4R5R6 

30,25 

4,56 

2,14 


Figure 1 1.22 — Duree estimee des chemins de I’exercice Recette aleatoire. 


Le chemin critique est R1R2R3R6 si Ton considere la duree estimee. Cepen- 
dant, la variance de R2R4R5R6 etant double de celle du chemin critique (pour 
une duree estimee de 30,25), il convient de surveiller egalement ce chemin. 

Les durees probables des differents chemins sont donnees a la figure 1 1.23. En 
effet : 


D(95) = D(est) + l,65xE(est) 
D(90) = D(est) + 1,28 xE (est) 
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Chemins 

D(95) 

D(90) 

R1R3R5R6 

38,38 

37,89 

R2R3R5R6 

33,86 

33,35 

R2R4R5R6 

33,77 

32,98 


Figure 1 1.23 — Durees probables de la Recette aleatoire. 


La probabilite d’une duree de 37 minutes se calcule sur le chemin critique. 

D(p) = D(est) + G(p) x E(est), soit : 37 = 36,17 + G(p).l,34 
G(p) = 0,619, d’ou l’on deduit que la probabilite est d’environ 72 %. 
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Le systeme d'information 
de pilotage 


Nous allons maintenant simuler partiellement le deroulement d’un petit projet. 
Vous en etes le chef. Apres avoir organise votre projet avec les ressources qui y 
ont ete affectees, vous allez le suivre regulierement au moyen de votre systeme 
d’information de pilotage. A la difference des cas proposes dans les autres chapi- 
tres de cette deuxieme partie, nous allons poser les questions au fur et a mesure 
de l’avancement simule du projet. Nous foumirons progressivement les informa- 
tions necessaires. Le corrige fera suite a la question. 

En fin de chapitre, nous proposons un exercice illustrant la methode de la 
valeur acquise (paragraphe 12.15), un autre sur la valeur monetaire attendue 
(paragraphe 12.16) et un troisieme sur le calcul de rentabilite avec la methode 
duROI (paragraphe 12.17). 


12.1 LE CAS PARKING 

Le projet a piloter est la realisation du projet Parking, dont vous avez estime la 
charge au chapitre 10. Vous commencez par organiser votre projet. 

Pour cela, vous ferez apparaitre les contraintes d’enchainement entre les 
taches en etablissant un graphe des antecedents. 

Vous disposez de deux ingenieurs, Claude et Camille. Le premier debute, la 
seconde a deux ans d’experience. Sur quels criteres allez-vous baser la repartition 
du travail ? Presentez l’affectation des taches dans un tableau. 


a 
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Votre client veut mettre en service son application le plus tot possible. Vous 
allez planifier le projet en consequence. Etablissez le diagramme de Gantt. Vous 
ferez les hypotheses suivantes : 

Vous commencez en debut du mois 1. Le mois 1 compte 31 jours. Le premier 
jour du mois 1 est un dimanche. Le mois 2 comprend 28 jours et aucun autre jour 
chome que les week-ends. Le mois 3 a 31 jours. Les 17 et 20 sont des jours feries. 
Le mois 4 est de 30 jours. Seuls les week-ends sont chomes. 

Par ailleurs, Camille souhaite partir dix jours en conge : il s’agit d’un reliquat 
de l’annee precedente que le service du personnel lui demande de prendre dans 
les trois prochains mois. 

Vous reprenez les resultats de votre evaluation analytique 1 . Nous les avons 
reproduits dans la figure 12.1. 


Remarques 

Les contraintes d’enchamement sont celles qui resultent de la nature meme 
des taches. Les lots seront consideres comme quasi independants. Le graphe des 
antecedents fera done apparaitre toutes les possibilites de parallelisme. 

Les tests se font sur la base de cas de figure choisis par le client. Ils preparent la 
recette officielle, qui aura lieu a la livraison de 1’ application. 


Lot 

Type de tache 

Nombre 

d’unites 

Poids standard 
ou ratio 

Charge estimee 
en jours-personne 

Parking 

Programmes temps 
reel moyen 

10 

3 jours-personne 

30 


Etude technique 


10% 

3 


Jeu essai 


20% 

6 


Tests 


7% 

2 

Vehicule 

Programmes temps 
reel moyens 

5 

3 jours-personne 

15 


Etude technique 


13 % 

2 


Tests 


10% 

1,5 


Figure 12.1 — Resultat de revaluation analytique du projet Parking. 


1. Elle figure au chapitre 10. Les donnees de base se trouvent au paragraphe 10.1.3 et le corrige 
au paragraphe 10.5. 



12.2. Corrige de I'organisation du projet Parking 




Autorisation 

Programmes temps 
reel difficiles 

5 

5 jours-personne 

25 


Etude technique 


8% 

2 


Jeu essai 


20% 

8 


Tests 


10% 

2,5 

Edition 

Programmes batch 
faciles 

10 

1,5 jours-per- 
sonne 

15 


Etude technique 


10% 

1,5 


Jeu essai 


20% 

3 


Tests 


10% 

1,5 

Integration 




10 

TOTAL 




128 jours-personne 


Figure 12.1 — Resultat de revaluation analytique du projet Parking. (Suite) 


12.2 CORRIGE DE ^ORGANISATION DU PROJET PARKING 

12.2.1 G raphe des antecedents du projet Parkins 

Le reseau est donne a la figure 12.2. La notation est la suivante : date debut, date 
fin. Lorsque les dates component des demi-journees, elles dont suivies de m 
(matin) ou a (apres-midi). 

Les quatre lots etant quasi independants, les seules contraintes a respecter 
sont les suivantes : 

• Pintegration ne peut se faire que sur les modules termines et testes ; 

• dans chaque lot, etude technique, programmation et test doivent se suivre ; 

• le jeu d’essai doit etre termine avant les tests. 

Le graphe possede done sept possibility de parallelisme au depart, que nous 
n’exploiterons que partiellement. 

Le delai normal donne par la formule de la methode Cocomo 1 est : 
delai normal = 2,5 x (6,4 mois-personne) 0,38 = 5 mois. 


1. Cette methode est presentee au paragraphe 3.7. 


a 
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1,3 

1,3 


0 


4 , 33 
4 , 33 


0 


34 , 35 
34 , 35 


0 



Figure 1 2.2 — Graphe des antecedents du projet 


La formule empirique pour les petits projets 1 de realisation donne un delai 
incompressible legerement inferieur : 

delai = 2,5 x (6,4 mois-personne) L 3 = 4,6 mois. 

Si on choisit d’effectuer le projet dans un delai plus court, on augmente de 
fagon importante les risques de depassement : en voulant raccourcir, on aboutit 
parfois au resultat inverse ! 


1. Proche de la formule proposee par la methode COCOMO. 


12.2. Corrige de I'organisation du projet Parking 


[289] 


12.2.2 Affectation des t aches du projet Parking 

L’affectation (figure 12.3) est un compromis a trouver entre les differentes 
contraintes. 


Intervenant 

Tache 

Charge 

Charge 

Charge 

initiale 

affectee 

actualisee 

Claude 

Lot Parking 





Jeu essai 

6 

8 



Etude technique 

3 




Programmation 

30 




Tests qualite 

2 




Total 


43 



Lot Edition 





Jeu essai 

3 




Etude technique 

1,5 




Programmation 

15 




Tests qualite 

1,5 




Total 


21 



Total Claude 


64 


Camille 

Lot Vehicule 





Etude technique 

2 




Programmation 

15 




Tests qualite 

1,5 




Total 


18,5 



Figure 12.3 — Affectation des taches du projet Parking. 
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Lot Autorisation 

Jeu essai 
Etude technique 
Programmation 
Tests qualite 
Total 

8 

2 

25 

2,5 

37,5 



Integration 

10 

10 



Total Camille 


66 



Figure 12.3 — Affectation des taches du projet Parking. (Suite) 


Claude debute : que faire de lui i Plusieurs solutions se presentent : 

• lui donner les taches les moins risquees ; souvent les debutants sont 
affectes aux taches de programmation ; on mise sur le fait que les tests 
debusqueront les fautes ; 

• lui confier les taches les plus faciles : la typologie des programmes nous y 
aide ; les editions sont souvent plus simples que le transactionnel ; 

• eviter de le mettre sur le chemin critique. 

Par ailleurs, le decoupage en lots doit etre pris en compte : 

• Si une meme personne prend en charge un lot complet, cela minimise le 
travail de mise au courant du dossier. Si on a deja fait l’etude technique, il 
est plus rapide de commencer la programmation. 

• En revanche, d’eventuelles erreurs ne seront pas debusquees par celui qui 
prendrait la suite du lot. 

• Mener a terme un lot complet est tres formateur et constitue une expe- 
rience riche. 

Si Ton considere qu’un intervenant presente un risque important, deux points 
de vue s’opposent : 

• Lui confier un lot complet confine les risques sur un seul element de 
livraison. 

• A l’inverse, l’affecter a une tache semblable sur plusieurs lots favorise un 
apprentissage specialise, mais diffuse le risque. 
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Un autre critere doit intervenir : l’equilibre entre les intervenants dans la 
repartition de la charge. Elle est ici de 128 jours. Les deux ingenieurs sont a 
temps plein, mais Camille a des vacances a prendre. II faudra integrer cette 
contrainte dans la planification. 

Pour le cas present, nous avons choisi une repartition minimisant l’effort de 
mise au courant et privilegiant l’interet pour les developpeurs. En effet, chacun a 
souhaite etre responsable d’une partie du projet : 

• La repartition se fait par lot complet. 

• Les lots Vehicule et Autorisation partagent le meme jeu d’essai. Celui qui a 
travaille sur l’un passera facilement a 1’ autre. 

• Les deux lots ci-dessus represented 56 jours-personne, soit un peu moins 
de la moitie de la charge globale qui est de 128 jours. 

• Le lot Edition etant le plus facile, nous le confions a Claude. 

• Nous confions les deux lots Vehicule et Automation a Camille, qui fera 
egalement l’integration. Sa charge est done de 66 jours. 

• Le lot restant, Parking, d’une charge de 46 jours, est confie a Claude. II 
faut remarquer que ce lot se situe sur le chemin critique, car e’est le plus 
grand des quatre. Cependant, sa difficult^ etant moyenne, nous prenons 
le risque de le donner a un debutant. 

• Pour prendre en compte la mise au courant de Claude, nous proposons, 
apres discussion avec lui, de lui affecter deux jours supplementaires pour 
la tache d’elaboration de jeu d’essai. C’est en effet une tache un peu deli- 
cate, qu’il n’a encore jamais faite. En effet, au cours de sa formation 
d’ingenieur il a surtout ete forme aux taches d’etude technique, program- 
mation et test. 

• La charge de Claude represente done 64 jours. 

Le tableau d’ affectation se presente done comme a la figure 12.3. 

12.2.3 Etablissement du planning 

Compte tenu de l’affectation precedemment realisee, nous avons etabli un plan- 
ning serre, sans aucun jour de battement sauf les jours feries. 

De plus, nous n’ avons prevu aucun moment pour faire le point : la faible 
taille de l’equipe favorisera la coordination personnelle. Nous veillerons a la 
rendre facile par une clarification des roles et une localisation geographique qui 
s’y prete. Si possible, les deux ingenieurs seront dans le meme bureau. 

Nous avons prefere planifier les conges de Camille juste avant l’integration, 
car sa charge hors integration est de 56 jours, alors que celle de Claude est de 
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64 jours. II y a done deja un decalage de 8 jours. Or, Camille ne peut commencer 
l’integration avant que Claude ait termine ses deux lots. 

Cela nous donne le calendrier de la figure 12.4, presente mois par mois. Les 
demi'journees sont indiquees par une case barree transversalement. 

Le projet commence le lundi 2 du premier mois. II se termine au milieu du 
mois 4, ce qui satisfait notre client. 

La duree totale du projet est de 106 jours, pour une charge de 130 jours. Le 
premier mois est le plus charge comme on le voit sur la figure 12.5. 
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Figure 12.4 — Planning du projet Parking. 


12.2. Corrige de I'organisation du projet Parking 
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Figure 12.4 — Planning du projet Parking. (Suite) 


Mois 
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Figure 12.5 — Repartition par mois de la charge et de la duree du projet Parking. 


12. Lesystdme d'information de pilotage 


0 


12.3 ENONCE DU RECAPIIULATIF MENSUEL DU PROJET PARKINS 

Claude et Camille vous remettent leur compte rendu d’avancement chaque 
semaine. Dresser les recapitulates mensuels par intervenant pour le mois 1 . 

Les comptes rendus d’avancement de la semaine du 2/1 au 8/1 sont donnes a 
la figure 12.6. Les comptes rendus d’avancement de la semaine du 9/1 au 15/1 
sont donnes a la figure 12.7. Les comptes rendus d’avancement de la semaine du 
16/1 au 22/1 sont donnes a la figure 12.8. Les comptes rendus d’avancement de 
la semaine du 23/1 au 29/1 sont donnes a la figure 12.9. Les comptes rendus 
d’avancement de la semaine du 30/1 au 5/2 sont donnes a la figure 12.10. 
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Figure 12.6 — Comptes rendus d’avancement de la semaine 1 . 
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Figure 12.7 — Comptes rendus d’avancement de la semaine 2. 
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Figure 12.8 — Comptes rendus d'avancement de la semaine 3. 
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Figure 12.9 — Comptes rendus d’avancement de la semaine 4. 
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Figure 12.10 — Comptes rendus d’avancement de la semaine 5. 


12. Le systdme d'information de pilotage 


s 


Le recapitulatif mensuel sera presente, par intervenant, comme a la 
figure 12.1 1. La legende est la suivante : 

• t = temps passe ; 

• r = reste a faire ; 

• a = avancement. 

Ces trois valeurs seront calculees pour chaque tache ouverte pendant la 
semaine, puis en recapitulatif dans la colonne total mois. Dans cette derniere 
colonne, on recapitulera egalement pour l’ensemble des taches du mois, le temps 
total passe et l’avancement total. 
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Figure 12.1 1 — Modele de recapitulatif mensuel. 


12.4 CORRIGE DU RECAPITULATIF MENSUEL DU PROJET PARKING 

A partir des valeurs des comptes rendus d’avancement du mois 1 , on obtient le 
tableau recapitulatif de la figure 12.12. 

Claude a mis un peu plus de temps que prevu sur le jeu d’essai. En revanche, 
il semble avoir pris un bon rythme sur les taches suivantes. 

Camille a ete tres rapide sur le jeu d’essai ; elle avance egalement plus vite 
que prevu sur la programmation vehicule. 

Ainsi l’avancement n’est pas forcement egal au temps passe. II peut etre supe- 
rieur (AutorisationJE ) ou inferieur (ParkingfE). 
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Figure 12.12 — Recapitulatif du mois 1 pour le projet Parking. 


Quelque chose doit attirer notre attention : c’est le temps qui n’est pas consa- 
ere au projet. Claude a manque un jour la premiere semaine et de nouveau un 
jour en semaine 4. Camille a ete malade toute la semaine 3. C’est a suivre de pres. 

12.5 ENONCE DU BILAN INDIVIDUEL MENSUEL DU PROJET PARKING 

Nous sommes a la fin du mois 2. Vous venez de dresser le recapitulatif mensuel. 
Dressez le bilan individuel mensuel du mois 2 pour chacun des intervenants. 

Le recapitulatif mensuel du mois 2 se presente comme a la figure 12.13. 

Le bilan individuel mensuel se presen tera comme a la figure 12.14 avec : 

coefficient d’ utilisation = temps passe/duree planifiee 
(pour le mois ou depuis le debut du projet) 
vitesse = avancement/temps passe 

performance = charge affectee x 100/( temps passe + reste a faire) 
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Figure 12.13 — Recapitulate du mois 2 pour le projet Parking. 
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Figure 12.14 — Modele de bilan individuel. 


12.6. Corrige du bilan individuel mensuel du projet Parking 
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12.6 CORRIGE DU BILAN INDIVIDUEL MENSUEL DU PROJET PARKING 

Le bilan de Claude se presente comme resume a la figure 12.15. 
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Figure 12.15 — Bilan de Claude pour le mois 2. 


Celui de Camille est donne a la figure 12.16. 
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Figure 1 2.1 6 — Bilan de Camille pour le mois 2. 
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12. Le systdme d'information de pilotage 


Les deux intervenants ne travaillent pas a temps plein sur le projet, comme le 
montrent leurs coefficients d’utilisation. Ceci est a surveiller de pres. 

La performance de Camille est satisfaisante, elle equilibre des lenteurs sur 
certaines taches par une rapidite sur d’autres. 

La vitesse de Claude sur la programmation Parking doit nous alerter : il faut 
faire le point avec lui et voir les difficultes qu’il rencontre. 


n .7 ENONCE DE LA GESTION DES ALEAS DU PROJET PARKING 


Nous sommes au mois 3. Le mardi 21 au soir, Claude se foule la cheville. Vous 
faites le point de son avancement au telephone, puis vous allez voir Camille pour 
savoir ou elle en est. Vous disposez de leurs comptes rendus d’avancement. 

Dressez le diagramme de Gantt permettant de comparer avancement planifie 
et deroulement du projet. 

Quel probleme y a-t-il ? Que faites-vous i 

Les comptes rendus d’activite de Claude sont donnes a la figure 12.17. II est 
arrete pendant trois jours. II pourra reprendre le lundi 27. 
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Fisure 12.17 — Comptes rendus d’avancement de Claude pour le mois 3. 
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Camille vous rappelle qu’elle a prevu de prendre quelques jours de conge. Ses 
comptes rendus d’activite se presentent comme a la figure 12.18. 
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Figure 12.18 — Comptes rendus d’avancement de Camille pour le mois 3. 


12.8 CORRIGE DE LA GESTION DES ALEAS DU PROJET PARKING 

Le deroulement du proj et peut se suivre sur des diagrammes de Gantt (figures 12.19, 
12.20 et 12.21). On a repris la planification initiale. L’avancement reel 
figure en grise. 

A la fin du premier mois (figure 12.19), on voit que Claude a pris trois jours 
de retard par rapport a la planification : il a commence la programmation Parking 
le 18 au lieu du 16 et il n’a pas travaille sur le projet le 27. 

Camille a attaque la programmation Vehicule avec trois jours d’avance, le 1 1 
au lieu du 16. Mais sa semaine d’absence la met finalement en retard de deux 
jours sur le calendrier. 
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En fin du deuxieme mois (figure 12.20), Claude a augmente son retard par ses 
absences repetees : 10, 22, 27 et 28. Avec un rythme normal, c’est-a-dire 
conforme a ce qui etait prevu, il a maintenant sept jours de retard. 

Camille a largement rattrape son retard sur la tache de programmation Vehi- 
cule, puisqu’elle termine avec un jour d’avance. En revanche, elle consomme 
davantage que prevu sur les tests, ce qui la place a un jour et demi de retard en 
fin de mois. 

Ou en sommes-nous le mercredi 22 au matin (figure 12.21) ? Claude aurait 
du commencer les tests de Parking le dernier jour du mois 2, le mardi 28. En fait, 
il termine la programmation Parking le mardi 21 du mois 3. Par rapport au plani- 
fie, il a 14 jours de retard. Comme il est sur le chemin critique, cela signifie que 
si l’on ne fait rien, le projet est en retard de pres de trois semaines calendaires. 
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Figure 12.20 — Deroulement du projet Parking (mois 2). 
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Figure 12.21 — Deroulement du projet Parking (mois 3). 
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12. Le systdme d'information de pilotage 



Quant a Camille, elle est en retard d’un jour et demi sur la fin planifiee de la 
programmation Autorisation. Comme elle annonce un reste a faire d’un jour, elle 
a en fait deux jours et demi de retard. Par ailleurs, elle part en conge le soir meme 
jusqu’au mardi 4 du mois suivant. 

L’essentiel est de reduire le chemin critique. II faut reaffecter certaines des taches 
de Claude. Vous jugez preferable de le laisser terminer le lot Parking, puisqu’il ne 
reste que les tests. En revanche, il faut demarrer immediatement le lot Edition. 

Camille accepte de differer legerement ses vacances, car elle avait prevu de ne 
voyager que le dimanche. Elle viendra travailler jeudi et vendredi matin pour 
terminer la programmation Autorisation et faire l’etude technique Edition. En 
echange, elle ne rentrera que le mercredi 5 apres-midi. Elle prendra son reliquat 
de conge apres la fin du projet ; vous allez le negocier avec le service du personnel. 

Vous vous chargez vous-meme du jeu d’essai Edition. 

De son cote, Claude accepte de venir travailler tous les samedis jusqu’a la fin 
du projet. II les recuperera par la suite. 

La tache d’integration commencera avant la fin du lot Edition. Celui-ci sera 
integre en dernier. 

La nouvelle planification se presente comme a la figure 12.22. 

Selon le nouveau calendrier, le projet se termine done avec quatre jours de 
retard. II faut soumettre immediatement cette proposition au maitre d’ouvrage et 
obtenir son accord. 

En cas de disaccord, il faudra soit negocier le report de certaines editions, soit 
chercher en urgence une ressource supplementaire. Cette demiere solution est 
couteuse, aussi bien en temps que financierement. Elle presente egalement un 
risque en ce qui conceme la qualite. 
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Figure 12.22 — Nouvelle planification du projet Parking. 


Tout evenement de la vie du projet doit etre consigne sur un journal de bord, 
qui permet ensuite de reconstituer ce qui s’est passe ou de retrouver la cause de 
certains retards. Un extrait d’un tel journal est donne a la figure 12.23. 
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12. Le systdme d'information de pilotage 


Mois 3 

Mardi 14 

La machine de test n ’a pu demarrer qu’ 9 h 50. 

Mercredi 15 

Appel de M. Dentre pour l’ organisation de la recette. Je dois lui envoy er un calendrier 
la semaine prochaine. 

Jeudi 16 
RAS. 

Vendredi 17 
Ferie. 

Lundi 20 
Ferie. 

Mardi 21 

Envoi du calendrier de recette (document numero 1996/45, date du 21/3). 

Mercredi 22 

Claude s’estfoule la cheville. II sera absent jusqu’a la fin de la semaine. Une nouvelle 
planification a ete etablie qui reporte la fin du projet au 21/4. Reunion a 14 heures 
avec M me Zort : le report est accepte. 

Figure 12.23 — Extrait du journal de bord du projet Parking. 

12.9 ENONCE DE L’AVANCEMENT DU PROJET PARKING 

En fin du mois 3, comme chaque mois, vous dressez le tableau d’avancement du 
projet. Les comptes rendus d’activite des deux demieres semaines du mois 3 sont 
ceux des figures 12.24, 12.25 et 12.26. Les autres ont ete donnes avec l’enonce 
de la question precedente au paragraphe 12.7. 

En ce qui vous conceme (figure 12.24), vous avez passe le mercredi et le jeudi a 
negocier avec votre client et avec le service du personnel. De plus le jeu d’essai 
Edition vous a pris plus de temps que prevu. Vous etes done venu travailler samedi 25. 


Mois 3 

Chef de projet 

lundi 

20 

mardi 

21 

mercredi 

22 

jeudi 

23 

vendredi 

24 

samedi 

25 

dimanche 

26 

Reste 
a faire 

EditionJE 

ferie 




1 

1 


2 


Mois 3 

Chef de projet 

lundi 

27 

mardi 

28 

mercredi 

29 

jeudi 

30 

vendredi 

31 

samedi 

dimanche 

Reste 
a faire 

EditionJE 

1 

1 






0 


Figure 12.24 — Compte rendu d’avancement du chef de projet apres I’accident de Claude. 


12.9. Enonce de I'avancement du projet Parkins 



Le compte rendu de Camille (figure 12.25) montre qu’elle a passe tout le 
vendredi 24 sur l’etude technique du lot Edition. 


Mois 3 

lundi 

mardi 

mercredi 

jeudi 

vendredi 

samedi 

dimanche 

Reste 

Camille 

20 

21 

22 

23 

24 

25 

26 

a faire 

AutorisationPGM 

ferie 

1 

1 





0 

EditionET 




1 

1 



0 


Mois 3 Camille 

lundi 

27 

mardi 

28 

mercredi 

29 

jeudi 

0 

vendredi 

31 

samedi 

dimanche 

Reste 
a faire 


conge 

conge 

conge 

conge 

conge 





Figure 12.25 — Compte rendu d'avancement de Camille apres I’accident de Claude. 


Le compte rendu de Claude est conforme a ce qui etait prevu (figure 12.26). 


Mois 3 
Claude 

lundi 

20 

mardi 

21 

mercredi 

22 

jeudi 

23 

vendredi 

24 

samedi 

25 

dimanche 

26 

Reste 
a faire 

ParkingTEST 

ferie 

1 

absent 

absent 

absent 



2 


Mois 3 
Claude 

lundi 

27 

mardi 

28 

mercredi 

29 

jeudi 

30 

vendredi 

31 

samedi 

dimanche 

Reste 
a faire 

ParkingTEST 

1 

1 






0 

EditionPGM 



1 

1 

1 



12 


Figure 12.26 — Compte rendu d’avancement de Claude apres son accident. 


Le tableau d’avancement du projet sera presente par lots. II aura la forme du 
tableau de la figure 12.27, avec : 

Evolution de charge pour le mois ecoule 
= temps passe - avancement 

Evolution de charge en jours depuis le debut du projet 
= temps passe + reste a faire a ce jour - charge initiale. 


a 


12. Le systdme d'information de pilotage 


Evolution de charge depuis le debut du projet en pourcentage 
= evolution de charge en jours x 100/charge initiale. 

Achevement en pourcentage 

= (Charge initiale - reste a faire a ce jour x 100/charge initiale 


Tableau d’avancement du projet : nom en fin de mois : mois 


Mois n - 1 

Mois n 

Recapitulatif projet 

Lots 

Temps passe 

Reste a faire 

Temps passe 

Reste a faire 

Avancement 

Evolution de charge 

Charge initiale 

Temps passe 

Evolution en jours 

Evolution en % 

Achevement en % 


























Figure 12.27 — Modele de tableau d’avancement. 


12.10 CORRIGE DE L’AVANCEMENT DU PROJET PARKING 

Nous allons d’abord etablir le recapitulatif mensuel du mois 3 (figure 12.28). 

Le tableau d’avancement etabli a partir des recapitulates mensuels des trois 
premiers mois se presente comme a la figure 12.29. 

Les deux colonnes Reste a faire (mois 2 et mois 3) comprennent toutes les 
taches du lot sur lesquelles il reste du travail, done en particulier toutes celles qui 
ne sont pas commencees. 

Ce tableau presente au maitre d’ouvrage lui permet de voir que les deux 
premiers lots sont termines, que le troisieme est en bonne voie et qu’il reste prim 
cipalement le lot Edition et l’integration. 

Le projet est acheve a 80 %. Jusqu’a ce jour, il a ete consomme 10 jours de 
plus que prevu, soit 8 % de la charge hors encadrement. 


12. 10. Corrige de I'avancement du projet Parking 


0 


Mois 3 


Semaine 1 

Semaine 2 

Semaine 3 

Semaine 4 

Semaine 5 

Total mois 

Nom 

Tache 

t 

r 

a 

t 

r 

a 

t 

r 

a 

t 

r 

a 

t 

r 

a 

t 

r 

a 





















Claude 





















ParkingPGM 

3 

6 

2 

5 

3 

3 

4 

0 

3 







12 

0 

8 


ParkingTEST 










1 

2 

0 

2 

0 

2 

3 

0 

2 


EditionPGM 













3 

12 

3 

3 

12 

3 


Total 
















18 

12 

13 

Camille 





















Autorisation.PGM 

3 

10 

3 

5 

7 

3 

4 

2 

5 

2 

0 

2 




14 

0 

13 


EditionET 










2 

0 

1,5 




2 

0 

1,5 


Total 
















16 

0 

14,5 





















Chef de 





















EditionJE 










2 

2 

1 

2 

0 

2 

4 

0 

3 


Figure 12.28 — Recapitulate du mois 3 pour le projet Parking. 


Tableau d’ avancement du projet Parking en fin de mois 3 


Mois 2 

Mois 3 

Recapitulate projet 

Lots 

Temps passe 1 

Reste a faire 

Temps passe 1 

Reste a faire 

Avancement 

Evolution 
de charge 

Charge initiate 

Temps passe 

Evolution 
en jours 

Evolution 
en % 

Achevemen 
en % 

Parking 

18 

10 

15 

0 

10 

+ 5 jours 

41 

53 

+ 12 jours 

+ 29 

100 

Vehicule 

5 

0 





18,5 

17 

- 1,5 jour 

-8 

100 

Autorisation 

14 

15,5 

14 

2,5 

13 

+ 1 jour 

37,5 

33 

- 2 jours 

-5 

93 

Edition 


21 

9 

13,5 

7,5 

+ 1,5 jours 

21 

9 

+ 1,5 jour 

+ 7 

36 

Integration 


10 


10 



10 

0 



0 

Total 

37 

56,5 

38 

26 

30,5 

7,5 jours 

128 

112 

10 jours 

+ 8% 

80% 


Figure 12.29 — Avancement du projet Parking au mois 3. 


12. Le systdme d'information de pilotage 


0 

12.11 ENONCE DU BILAN DU PROJET PARKING 


En fin de projet, vous dressez le bilan de projet. 

Le recapitulatif mensuel du mois 4 est donne a la figure 12.30. La semaine 1 
ne comporte qu’un seul jour, le samedi. Le projet s’est termine le 22 du mois 4. 


Mois 4 


Semaine 

1 

Semaine 

2 

Semaine 

3 

Semaine 

4 

Semaine 

5 

Total 

mois 

Nom 

Tache 

t 

r 

a 

t 

r 

a 

t 

r 

a 

t 

r 

a 

t 

r 

a 

t 

r 

a 





















Claude 





















EditionPGM(l) 

1 

6 

0 

6 

3 

3 

6 

0 

3 







13 

0 

6 


EditionTEST 










2 

0 

1,5 




2 

0 

1,5 


Total 
















15 

0 

7,5 





















Camille 





















AutorisationTEST 




3 

0 

2,5 










3 

0 

2,5 


EditionPGM(2) 




1 

2,5 

0,5 

3,5 

0 

2,5 







4,5 

0 

3 


Integration 







2,5 

7 

3 

6 

0 

7 




8,5 

0 

10 


Total 
















16 

0 

15,5 





















Chef de 





















EditionPGM(3) 




3 

0 

3 










3 

0 

3 






















Figure 12.30 — Recapitulatif du mois 4 pour le projet Parking. 


Vous aviez sous-estime la complexity du generateur d’edition. Claude vous a 
fait part de ses difficultes pour generer des listes un peu compliquees. II restait 
huit programmes a ecrire sur les dix. 

Vous avez decide de partager le travail entre vous trois. Vous avez confie deux 
programmes du lot Edition (duree estimee a trois jours) a Camille, vous en avez 
pris deux autres et laisse les quatre demiers a Claude. 


12. 12. Corrige du bilan du projet Parking 


El 


12.12 CORRIGE DU BILAN DU PROIET PARKING 


Nous dressons d’abord un tableau d’avancement final (figure 12.31). 


Tableau d’avancement du projet Parking en fin de mois 4 


Mois 3 

Mois 4 

Recapitulate projet 

Lots 

Temps passe 

Reste a faire 

Temps passe 

Reste a faire 

Avancement 

Evolution de charge 

Charge initiale 

Temps passe 

Evolution en jours 

Evolution en % 

Achevement en % 

Parking 

15 

0 





41 

53 

+ 12 jours 

+ 29 

100 

Vehicule 

0 

0 





18,5 

17 

-1,5 jour 

-8 

100 

Autorisation 

14 

2,5 

3 

0 

2,5 

+ 0,5 jour 

37,5 

36 

-1,5 jour 

-4 

100 

Edition 

9 

13,5 

23,5 

0 

13,5 

+ 10 jours 

21 

315 

+ 10 ,5 jours 

+ 50 

100 

Integration 

0 

10 

8,5 

0 

10 

-1.5 jour 

10 

85 

-1,5 jour 


0 

Total 

38 

26 

35 


26 

+ 9 jours 

128 

146 

+ 18 jours 

+ 14 



Figure 12.31 — Avancement du projet Parking au mois 4. 


Globalement, le projet a consomme 146 jours hors encadrement, soit 14 % 
de plus que prevu. Nous allons etudier par type de tache ou s’est cree l’ecart 
(figure 12.32). Nous reprenons pour cela la typologie qui a servi de base a 1’ esti- 
mation analytique. 


Type tache 

Nombre 

Charge 

estimee 

Charge 

constatee 

Ecart 

% 

Jeu essai 

3 

17 

18 

1 

6 

Etude technique temps reel 

3 

7 

7 

0 

0 

Etude technique hatch 

1 

1,5 

2 

0,5 

33 

Programme moyen temps reel 

15 

45 

50 

5 

11 

Programme difficile temps reel 

5 

25 

26 

1 

4 


Figure 12.32 — Ecarts de charge du projet Parking. 


12. Le systdme d'information de pilotage 


0 


Programme batch facile 

10 

15 

23,5 

8,5 

57 

Test 

4 

7,5 

11 

3,5 

47 

Integration 

1 

10 

8,5 

- 1,5 

-15 

Total 


128 

146 

18 

14 


Fisure 12.32 — Ecarts de charge du projet Parking. (Suite) 


L’ecart le plus important a ete observe sur la programmation batch, que Ton 
jugeait facile. 


12.13 ENONCE DE LA CAPITALISATION D’EXPERIENCE 
DU PROJET PARKING 

Vous allez capitaliser l’experience issue de ce projet. 

1. Faites le suivi du poids des unites d’oeuvre (parametres) et de la valeur des 
ratios appliques. Le suivi des unites d’oeuvre se presentera comme a la 
figure 12.33. Le suivi des ratios se fera ainsi selon la figure 12.34. 

2. Terminez par une fiche recapitulative du projet. Celle-ci comprendra un 
bref resume du projet ainsi que les caracteristiques de son deroulement. 


Suivi des unites d’oeuvre du projet 

Type 

tache 

Valeur 
de l’unite 
d’oeuvre 

Nombre 

d’unites 

d’oeuvre 

Charge 

moyenne 

constatee 

Ecart 

Ecart- 

type 

Programme 
moyen temps 
reel 






Programme 
temps reel 
difficile 






Programme 
batch facile 







Figure 12.33 — Modele de suivi des unites d’oeuvre. 


12. 14. Corrige de la capitalisation d'experience du projet Parking 


a 


Suivi des ratios du projet 

Type 

Charge 
estimee de 
programmation 

Ratio 

Charge 
reelle de 
programmation 

Charge 

constatee 

Ratio 

Ecart 

tache 

standard 

du type 
de tache 

constate 

Jeu essai 







Etude 

technique 







Test 








Figure 12.34 — Modele de suivi des ratios. 


12.14 CORRIGE DE LA CAPITALISATION D'EXPERIENCE DU PROJET PARKING 

Le suivi des unites d’oeuvre fait apparaitre les ecarts donnes a la figure 12.35. 

Pour les programmes temps reel de difficult e moyenne, nous ne disposons pas du 
detail de charge constatee pour chacun des quinze programmes : dix dans le lot 
Parking et cinq dans le lot Vehicule. En effet, on a fait une tache unique pour 
l’ensemble des programmes de chaque lot. On calcule done la moyenne entre les 
deux taches : 


Charge moyenne constatee = 50/15 = 3,3 jours. 

L’ecart-type mesure la distance a la moyenne. Ici, nous n’avons que deux valeurs. 
Pour le lot Parking, la duree moyenne pour le lot est de : 38/10 = 3,8 jours. Pour 
le lot Vehicule, la duree moyenne pour le lot est de : 12/5 = 2,4 jours. Done un 
ecart important entre les deux. La dispersion par rapport a la moyenne est de : 

Ecart-type = [10(3,8 - 3,3) 2 + 5(2,4 - 3,3) 2 P / 15 
= 0,17. 

Pour les programmes temps reel difficiles, Pecan- type n’a pas de sens puisque 
nous n’avons qu’une seule valeur, celle du lot A utorisation. 

Pour les editions batch, nous n’avions au depart qu’une seule tache compre- 
nant les dix programmes. Mais la repartition sur plusieurs personnes au cours du 
deroulement du projet (voir paragraphes 12.8 et 12.9) donne une visibility plus 
fine. 

On a les chiffres suivants : Claude a fait six programmes en deux fois, Camille 
deux et le chef de projet deux. 


12. Le systdme d'information de pilotage 


El 


D’apres les recapitulates mensuels des mois 3 et 4, nous avons les valeurs 
suivantes : 

• Claude au mois 3 : 2 programmes en 3 jours, soit 1,5 jour en moyenne. 

• Claude au mois 4 : 4 programmes en 13 jours, soit 3,25 jours en moyenne. 

• Camille au mois 4 : 2 programmes en 4,5 jours, soit 2,25 jours en moyenne. 

• Chef de projet au mois 4 : 2 programmes en 3 jours, soit 1,5 jours en 
moyenne. 

La charge moyenne constatee est de 23,5/10 = 2,4 jours (apres arrondi). 
L’ecart entre les moyennes est important, puisqu’elles vont de 1,5 a 3,25. La 
dispersion est mesuree par : 

ecart-type = [2(1,5 — 2,4) 2 + 4(3,25 - 2,4) 2 
+ 2(2,25 - 2,4) 2 + 2(3 - 2,4) 2 ] 1/2 / 10 
= 0,23. 


Type tache 

Valeur de 
l’unite d’ceuvre 
en jours-personne 

Nombre 

d’unites 

d’ceuvre 

Charge 

moyenne 

constatee 

Ecart 
en jours/ 
homme 

Ecart 

-type 

Programme 
moyen temps reel 

3 

15 

3,3 

0,3 

0,66 

Programme temps 
reel difficile 

5 

5 

5,2 

0,2 


Programme batch 
facile 

1,5 

10 

2,4 

0,9 

0,23 


Figure 12.35 — Suivi des unites d'oeuvre du projet Parking. 


Le suivi des ratios (figure 12.36) fait apparaitre des ecarts faibles (un ou deux 
points) : cela signifie qu’il y a effectivement une relation de proportionnalite 
forte entre la charge de programmation et celle des charges peripheriques. 


Type 

tache 

Charge 
estimee de 
programmation 

Ratio 

standard 

Charge 
reelle de pro- 
grammation 

Charge 
constatee 
du type de 
tache 

Ratio 

constate 

Ecart 

Jeu essai 

85 

20 

99,5 

18 

18 

2 

Etude 

technique 

85 

10 

99,5 

9 

9 

1 

Test 

85 

10 

99,5 

11 

11 

1 


Figure 12.36 — Suivi des ratios du projet Parking. 


12. 15. La methode de la valeur acquise 


a 


La fiche recapitulative de projet se presente comme illustree a la figure 12.37. 


Projet Parking 

Deroulement : 2/1/96 au 22/4/96 
Nature du projet : 

II s’agissait d’un projet de realisation. L’ application permet de gerer 1’ attribution de 
places de parking, en prenant en compte des regies specifiques. Pour faciliter revolu- 
tion du systeme, les regies ont ete externalisees et peuvent etre mises a jour directe- 
ment par les gestionnaires. De nombreux etats de gestion ont ete founds. 

Le developpement s’est fait dans un environnement AS400. 

Caracteristiques : 

Le dossier de specification etait correctement documents et toutes les maquettes 
foumies. 

Remarque : 

L’ecart de charge sur les programmes d’edition a deux causes. D’une part, la prise en 
main du nouveau generateur d’etats n’a pas ete immediate. D’autre part, ces editions 
ont ete en grande partie confiees a un debutant, qui a mis beaucoup plus de temps que 
prevu. La charge moyenne de 2,4 jours au lieu des 1,5 prevus s’explique ainsi. 

Figure 12.37 — Fiche recapitulative du projet Parkins. 

Les trois elements de capitalisation du savoir-faire (suivi des unites d’oeuvre, 
suivi des ratios et fiche recapitulative) viennent alimenter la base d’experiences des 
participants, notamment si cette demiere a fait l’objet d’une informatisation. Ils 
enrichissent et affinent les evaluations de charge qui seront faites ulterieurement. 


12.15 LA METHODE DE LA VALEUR ACQUISE 

12.15.1 Enonce de I’exercice sur la valeur acquise 

Soit le projet de la figure 12.38. 


Taches 

Predecesseur 

Duree (semaines) 

Cout planifie (en K€) 

A 


2 

5 

B 

A 

6 

12 

C 

A 

5 

10 

D 

C 

3 

9 




36 


Figure 1 2.38 — Taches du projet a suivre. 


12. Le systdme d'information de pilotage 


Ce qui donne le reseau des antecedents de la figure 12.39. 



1) Calculer la VP en fin de chaque semaine, en supposant une repartition 
proportionnelle des couts en fonction du temps. On indiquera pour chaque 
tache le cout genere chaque semaine. Dans une ligne Total on calculera la VP du 
projet, c’est-a-dire les couts cumules en fin de chaque semaine. 

2) Les couts reels et le pourcentage d’achevement a la fin de la semaine 5 sont 
donnes a la figure 12.40. Calculer le CR et la VA a la fin de chaque semaine, 
ainsi que l’ecart de delai et l’ecart de cout (VC : Value cost). 


Tache 


1 

2 

3 

4 

5 

A 

reel 

% acheve 

3 

40% 

2 

100% 




B 

reel 

% acheve 



1 

25% 

4 

35% 

2 

55% 

C 

reel 

% acheve 



2 

20% 

2 

40% 

2 

50% 


Figure 1 2.40 — Avancement reel du projet a suivre. 


3) Calculer, en fin de semaine 5 : 

• l’indice de performance des couts (IPC), 

• l’indice de performance des delais (IPD), 

• l’indice de performance des couts cumule (IPCC) 

• l’indice de performance requis (IPR) pour respecter l’enveloppe budgetaire. 


12. 15. La methode de la valeur acquise 


El 


• la PAA (prevision a l’achevement), d’abord si les ecarts sont accidentels, 
puis si les ecarts sont representatifs du futur. 

12.15.2 Corrige de I'exercice sur la valeur acquise 

Le corrige de la VP pour l’ensemble du projet est donne au tableau de la 
figure 12.41. 


Semaine - Tache 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

A 

2,5 

2,5 









B 



2 

2 

2 

2 

2 

2 



C 



2 

2 

2 

2 

2 




D 








3 

3 

3 

VP du projet (K€) 

2,5 

5 

9 

13 

17 

21 

25 

30 

33 

36 


Figure 12.41 — Cout du travail planifie 
pour I’ensemble du projet. 


Le corrige des indicateurs economiques jusqu’a la fin de la semaine 5 est donne 
au tableau de la figure 12.42. Pour la VA, on a indique la formule de calcul. 



1 

2 

3 

4 

5 

A (5 K€) 
planifie 

2,5 

2,5 




reel 

3 

2 




% acheve 

40% 

100% 






(+ 60 %) 




B (12 K€) 
planifie 



2 

2 

2 

reel 



1 

4 

2 

% acheve 



25% 

35% 

55% 





(+ 10 %) 

(+ 20 %) 

C (10K€) 
planifie 



2 

2 

2 

reel 



2 

2 

2 

% acheve 



20% 

40% 

50% 





(+ 20 %) 

(+ 10 %) 


Figure 12.42 — Indicateurs economiques du projet a la semaine 5. 
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1 

2 

3 

4 

5 

CR 

ce qu ’on a depense 

3 

5 

8 

14 

18 

YA 

ce qu ’on aurait 

2 

5 

10 

13,2 

16,6 

du depenser pour 
le travail acheve 

40 %.5 

100 %.5 

5 + 

25%. 12 + 
20%. 10 

10 + 

10%. 12 + 
20 %. 10 

13,2 + 
20%. 12 + 
10 %.10 

VP 

ce qu ’on a budgete 
et planifie de faire 

2,5 

5 

9 

13 

17 

Ecart de delai : 
VA-VP 

-0,5 

(retard) 

0 

1 

(avance) 

0,2 

(avance) 

-0,4 

(retard) 

Ecart de cout : 
VA-CR 

sur- 

consom- 

mation 

0 

2 

sur- 

consom- 

mation 

-0,8 

sur- 

consom- 

mation 

-1,4 

sur- 

consom- 

mation 


Figure 12.42 — Indicateurs economiques du projet a la semaine 5. (Suite) 


En fin de semaine 5, nous obtenons les valeurs suivantes : 

• Indice de performance des couts (IPC) = VA/CR = 16,6/18 = 0,92 

• Indice de performance des delais (IPD) = VA/VP = 16,6/17 = 0,98 

• Indice de performance des couts cumules (IPCC) = (D VA)/(X CR) 
= (2 + 5 + 10 + 13,2 + 16,6)/(3 + 5 + 8 + 14 + 18) = 46,8 / 48 = 0,98 

• Indice de performance requis (IPR) = Travail restant/Budget restant 
= (45 % B) + (50 % C) + D/(36 - 18) = 5,4 + 5 + 9 / 18 = 19,4 / 18 
= 1,08 

La prevision a l’achevement se presente comme suit. 

• Si les ecarts sont accidentels, 

PAA = Couts reels + Travail restant = 18 + 19,4 = 37,4 

• Si les ecarts sont representatifs du futur, 

PAA = Couts reels + Travail restant/IPC = 18 + (19,4/0,92) = 18 + 21,09 
= 39,09 

• ou bien avec 1’ indice de performance des couts cumule : 

PAA = Couts reels + Travail restant/IPC c = 18 + (19,4/0,98) = 18 + 19,8 
= 37,8 
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12.16 LA VALEUR MONETAIRE ATTENDUE 

12.16.1 Enonce de la VMA 

Vous etes attentif aux couts de votre projet, mais vous avez aussi des contraintes 
de delai (interessement/penalites en cas d’avance/retard). Vous etes obliges de 
faire appel a une equipe exterieure que vous payez proportionnellement au temps 
travaille et au profil des ressources (regie simple). Vous hesitez entre trois equipes 
sur lesquelles vous avez les renseignements suivants. 

Equipe CapMidi 

Le prix annonce est de 9000. Ce prestataire a l’habitude de terminer dans les 
temps, mais de facturer plus cher que le prix annonce, en affectant des ressources 
plus qualifiees, mais plus cheres. La probability qu’il respecte le budget est de 
10 %. II a cependant 20 % de chances d’augmenter le prix de 15 %, 40 % de 
l’augmenter de 30 % et 30 % de l’augmenter de 50 %. 

Equipe InfoCom 

Le prix annonce est de 12 000. Le prix sera respecte, mais ces intervenants 
peuvent etre en retard. La probability qu’ils respectent le delai est de 30 %. Ils 
ont 20 % de chances d’etre en retard de 20 jours, ce qui represente pour vous une 
penalite de 2000 pour votre projet, et ils ont 50 % de chances d’etre en retard de 
10 jours, ce qui correspond a une penalite de 1000. 

Equipe Dafne 

Le prix annonce est de 13 000. Le prix annonce sera respecte, mais ce prestataire 
peut aussi bien etre en avance qu’en retard. Plus precisement, il a 60 % de chan- 
ces d’etre dans les delais, 20 % de chances d’avoir un leger retard correspondant 
pour vous a une penalite de 500, et 20 % de chance d’etre en avance ce qui vous 
procurerait un interessement de 800. 

Dressez un arbre de decision pour montrer les raisons du choix que vous allez 
faire en vous appuyant sur la valeur monetaire attendue de chaque scenario. 

12.16.2 Corrige de la VMA 

Le tableau de la figure 12.43 recapitule le calcul de la valeur du scenario attache 
a chacun des trois foumisseurs potentiels. Nous voyons que le choix devrait se 
porter sur CapMidi qui probablement coutera le moins cher. 
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Scenario 

Depenses 

Probabilite 
gain ou 
perte 

Montant 
gain ou 
perte 

Probabilite 
* Montant 
gain ou 
perte 

VMA 

Equipe 

CapMidi 


10% 

0 





20% 

-1350 

-270 




40% 

-2 700 

-1080 




30% 

-4 500 

-1350 



-9 000 



-2 700 

- 11 700 

Equipe 

InfoCom 


30% 

0 





20% 

-2 000 

-400 




50% 

-1000 

-500 



- 12 000 



-900 

- 12 900 

Equipe 

Dafne 


60% 

0 





20% 

-500 

-100 




20% 

800 

160 



- 13 000 



60 

- 12 940 


Figure 12.43 — Calcul de la VMA 


1117 LE CALCUL DE RENTABILITE 

12.17.1 Enonce des indicateurs du ROI 

Soit a evaluer la rentabilite d’un projet ERP (SAP/R3) dans une entreprise 
intemationale (France, Belgique, Allemagne et Suede). Le perimetre du projet 
comprend quatre modules : SD (Sales and Distribution), FI (Financial Accounting), 
PP ( Production planning) et MM ( Material management). Les objectifs financiers 
de l’implementation sont les suivants. On cherche a reduire les couts du service 
Administration des ventes (automatisation, reduction du besoin de coordina- 
tion personnelle) par la suppression de trois postes de travail et la diminution des 
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besoins de transport. On veut aussi reduire les delais de paiement par les clients 
et passer de 75 a 70 j. On va revoir les procedures de la fonction Comptabilite 
(automatisation, disponibilite de l’information), ce qui devrait diminuer le 
nombre de reunions intemationales. On vise enfin de reduire le volume des 
stocks de 40 % en moyenne sur l’annee et d’augmenter leur rotation des stocks 
en passant de 30 jours a 15 jours. 

Les estimations (en K€) sont donnees au tableau de la figure 12.44 : 


Annee 

Depenses 

Gains 

1 

Modules SD, MM et FI 

700 

0 

2 

Assistance externe 
Redevance SAP 

1400 

300 

3 

Assistance externe 
Module PP 
Redevance SAP 

1 300 

1000 

4 

Assistance externe 
Redevance SAP 

1 150 

2 000 

5 

Redevance SAP 
Maintenance 

950 

2 500 

6 

Redevance SAP 
Maintenance 

900 

3 000 

7 

Redevance SAP 
Maintenance 

1 000 

3 000 

8 

Redevance SAP 
Maintenance 

1 500 

3 000 

Total 


8 900 

14 800 


Figure 12.44 — Estimations pour le calcul du ROI 


En supposant un taux actualisation de 4,5 % et une duree de vie de l’investis- 
sement de 8 ans, calculer le delai de remboursement, les gains et depenses actua- 
Uses, la VAN et le TRI. 

Si Ton utilise un tableau Excel, les fonctions se parametrent de la fagon suivante : 

• VAN (taux % ; cellule debut Cash-flow ; cellule fin Cash-flow). 

• TRI (cellule debut Cash-flow ; cellule fin Cash-flow). 
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12,17.2 Corrige des indicateurs du ROI 

Le delai de remboursement se situe entre l’annee 4 et l’annee 5 (figure 12.45). 
Les chiffres donnes au tableau de la figure 12.46 montrent que la valeur actuelle 
nette est de 4154, ce qui correspond a taux de rentabilite interne de 37 %. 



- Depenses 
actualisees 

- Gains actualises 


- Cash-flow actualise 
cumule 


Figure 12.45 — Delai de remboursement 


Annee 

1 

2 

3 

4 

5 

6 

7 

8 

Depenses 

700 

1400 

1300 

1 150 

950 

900 

1000 

1500 

Gains 

0 

300 

1000 

2 000 

2 500 

3 000 

3 000 

3 000 

Cash-flow (gains-depenses) 

-700 

-1 100 

-300 

850 

1550 

2100 

2 000 

1500 

Cash-flow cumule 

-700 

-1800 

-2 100 

-1250 

300 

2400 

4400 

5 900 

Cash-flow actualise 

-670 

-1007 

-263 

713 

1244 

1613 

1470 

1055 

Cash-flow actualise cumule 

-670 

-1677 

-1940 

-1 227 

17 

1629 

3 099 

4154 


Figure 12.46 — Calcul du ROI 


Ainsi s’acheve la mise en pratique du pilotage d’un projet, avec le dispositif 
de suivi, le calcul de la performance et une illustration de quelques techniques 
d’aide aux decisions d’ordre financier. 
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La dimension relationnelle 
des projets 


Nous allons illustrer la dimension relationnelle des projets sous deux angles. Le 
premier concerne le management de l’equipe de projet. Le second presente les 
difficultes que Ton peut rencontrer avec d’autres acteurs de l’entreprise. 

13.1 LE MANAGEMENT DEQUIPE 


Vous etes confronte a diffe rentes situations qui appellent une prise de decision. 
Differents comportements vous sont proposes. 

II vous est demande : 

• d’indiquer a quel style de management correspond chacune des conduites ; 

• de presenter les avantages et les inconvenients de chaque choix ; 

• d’eventuellement conseiller une solution, si elle vous semble preferable ; 

• et d’eventuellement deconseiller une des solutions si elle vous parait trop 
risquee ou inadequate. 

13*1*1 Enonce de r affectation de nouvelles ressources 

Bernard et Jean, ayant environ deux ans d’experience, viennent d’etre recrutes 
et sont affectes a votre projet. Vous hesitez quant aux taches a leur confier. 
Bernard est « fana » de technique, mais il vous semble important qu’il s’implique 
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egalement dans les jeux d’essais et dans les seances de validation avec les utilisa- 
teurs. Jean est polyvalent, mais un peu timide. 

1. Vous dialoguez avec Jean et Bernard pour leur montrer l’importance 
d’une activite diversifiee pour le projet comme pour leur propre evolution 
de carriere. 

2. Vous leur confiez deux lots complets avec une date de fin des deux lots et 
une charge estimee pour chaque tache, charge a eux de se repartir le 
travail et de vous donner le planning detaille le lendemain. 

3. Vous les rencontrez chacun separement pour leur demander leur avis. Si 
Bernard reste determine a ne faire que du developpement, vous effectuez 
une repartition specialisee des taches. 

4. Vous confiez a chacun un lot complet et vous demandez a Henri, un 
membre de votre equipe qui a une grande experience, de prevoir une 
demi-journee de formation pour Bernard. 

13.1.2 Corrige de I’ affectation de nouvelles ressources 

La qualification des attitudes est donnee a la figure 13.1. 



Style 

Avantages 

Risque ou inconvenients 

■ 

Persuasif 

Favorise l’integration 
des nouveaux. 
Corneille 

Pas de decision. 

2 

Par delegation 


Dangereux pour le projet. 

Risque de conflits entre Bernard 
et Jean. 

Deconseille 

3 

Participatif 

individuel 

Augmente la satis- 
faction individuelle 

Baisse de la polyvalence de l’equipe. 
Reduction de souplesse pour le projet. 

4 

Directif seul 

Decision rapide. 

Ne favorise pas 1’ adhesion au projet. 


Figure 13.1 — Styles de manasement pour I’affectation des ressources. 


13.1.3 Enonce d’un probleme avec un groupe de validation 

Vous avez adopte une demarche RAD, et le projet se trouve a l’etape de construc- 
tion. Charles, responsable du premier lot, vient d’avoir la premiere session de 
validation de prototype. L’equipe de validation est composee de cinq personnes : 
une n’est pas venue, deux ont passe une partie de la session a traiter un probleme 


13. 1. Le management d'equipe 


g 


operationnel sans rapport avec leur prototype. Seules deux personnes sur cinq ont 
vraiment participe a la session. La prochaine doit avoir lieu dans deux semaines. 

1. Vous organisez une reunion avec l’ensemble de l’equipe de projet (hors 
utilisateurs) et vous recherchez ensemble des moyens d’agir. 

2. Vous allez voir chaque personne du groupe de validation, accompagne du 
chef de projet utilisateur, pour leur expliquer a nouveau l’importance du 
pro jet et de leur role. 

3. Vous expliquez a Charles qu’il doit etre plus ferme. Vous lui conseillez 
d’envoyer un mail de rappel au groupe de validation quelques jours avant 
la prochaine session. 

4- Vous faites le point avec Charles et avec le chef de projet utilisateur, puis 
vous demandez au president du Comite de pilotage d’organiser une 
reunion avec le groupe de validation et le chef de projet utilisateur. Au 
cours de cette reunion, vous rappelez que l’objectif de delai et qualite doit 
etre partage par tous les acteurs du projet et que cela implique un respect 
des regies du jeu par chacun. Vous insistez sur le fait que le groupe de vali- 
dation doit etre libere pour participer aux sessions. 

13.1 .4 Corrige d’un probleme avec un groupe de validation 

La qualification des attitudes est donnee a la figure 13.2. 



Style 

Avantages 

Risque ou inconvenients 

1 

Participatif 

groupe 


Ne touche pas les acteurs 
concemes (utilisateurs). 
Risque de dresser l’equipe de 
projet contre les utilisateurs. 
Deconseille 

2 

Persuasif 

Evite de creer des perturba- 
tions chez la maitrise 
d’ouvrage. 

Resultat incertain si les 
contraintes operationnelles 
du groupe de validation sont 
fortes. 

3 

Par delegation 


Risque de destabiliser Charles. 
Resultat peu garanti. 
Deconseille 

4 

Directif apres 
information 

Les regies ont besoin d’etre 
rappelees aussi bien a 
l’equipe de validation qu’au 
Comite de pilotage. 
Conseille 



Figure 1 3.2 — Styles de management pour un probleme avec un groupe de validation. 
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13.13 Enonce d’un retard sur un sous -projet 

Votre projet comporte quatre sous-projets ayant chacun un responsable. Vous 
avez une reunion d’avancement tous les lundis matins. Vendredi apres-midi, 
vous prenez connaissance du tableau de bord hebdomadaire qui vient de vous 
parvenir et vous constatez un retard important du sous-projet dirige par Domini- 
que. Jusque-la, vous n’avez connu aucun probleme majeur. 

1. Vous attendez la reunion de lundi pour que Dominique vous explique les 
raisons du retard et les actions qu’elle va mettre en oeuvre. 

2. Vous appelez immediatement Dominique pour la rencontrer avec son equipe 
afin d’ analyser le retard et de mettre en place des mesures de redressement. 

3. Vous convoquez les quatre responsables de sous-projets pour une reunion 
exceptionnelle et vous recueillez les explications de Dominique et les avis 
des autres, en vue de prendre des mesures que vous annoncerez lundi matin. 

4. Vous envoyez un mail a Dominique pour lui rappeler l’importance des 
delais et lui demander de preparer des propositions d’ action pour la 
reunion de lundi. 

13.1.6 Corrige d’un retard sur un sous-projet 

La qualification des attitudes est donnee a la figure 13.3. 



Style 

Avantages 

Risque ou inconvenients 

■ 

Par delegation 

Pas de dramatisation. 
Mise sur la confiance. 
Corneille 

Retard a reagir si Dominique 
n’a rien prepare. 

2 

Participatif 

groupe 


Dominique est mise en diffi- 
culte devant son equipe. 
Risque d’une reaction de bloc 
de 1’ equipe de sous-projet. 
Deconseille 

3 

Consultatif 

groupe 

+ 

Directif seul 


Brutal et eprouvant pour 
Dominique. 

Risque de demotivation de 
1’ equipe de Dominique. 
Risque de mauvais climat 
dans 1’ equipe de projet. 
Deconseille 

4 

Persuasif 

Dominique sera preparee et 
aura eu le temps de reflechir, 
eventuellement avec son 
equipe. 



Fisure 13.3 — Styles de management pour un retard sur un sous-projet. 
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13.1.7 Enonce d’un retrait de ressources 

Votre projet comporte quatre sous-projets ayant chacun un responsable. Le 
Directeur informatique vient de vous informer que deux personnes (travaillant 
chacune sur un sous-projet) sont retirees immediatement du projet a cause d’une 
urgence sur un projet prioritaire. La date d’achevement de votre projet (dans un 
mois) est maintenue. 

1. Vous reflechissez a differentes solutions, puis vous convoquez l’ensemble 
de l’equipe pour decider de la meilleure solution. 

2. Vous convoquez les responsables de sous-projet. Vous leur expliquez 
pourquoi l’autre projet est prioritaire. Vous leur demandez de trouver une 
solution pour le lendemain. 

3. Vous demandez leur avis a chaque responsable de projet et vous cherchez 
la solution la moins perturbatrice que vous exposez le lendemain. 

4- Vous rencontrez successivement les responsables des deux sous-projets 
touches et vous cherchez avec eux une solution acceptable. 

13.1.8 Corrige d’un retrait de ressources 

La qualification des attitudes est donnee a la figure 13.4. 



Style 

Avantages 

Risque ou inconvenients 

1 

Participatif 

groupe 


Court-circuite les responsa- 
bles de sous-projet. 

Risque de destabiliser 
l’equipe de projet. 
Deconseille 

2 

Persuasif 

+ 

Par delegation 

Fait confiance aux responsa- 
bles de sous-projet. 

Risque de conflit entre les 
responsables de sous-projet. 
Risque de retard accru pour 
le projet. 

3 

Consultatif 

+ 

Directif seul 

Rapidite de la decision. 
Evite des conflits entre les 
responsables de sous-projet. 
Corneille 


4 

Participatif 

individuel 

Evite de perturber deux des 
quatre sous-projets. 

Besoins d’allers-retours entre 
les deux responsables. 

11 est peut-etre necessaire 
d’utiliser certaines ressources 
des sous-projets non touches. 


Fisure 13.4 — Styles de manasement pour un retrait de ressources. 
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13.1.9 Enonce de la mise en place d’un intranet pour !e projet 

Le projet a demarre depuis peu et vous allez mettre un intranet, deja utilise sur 
d’autres projets, pour favoriser la communication et faciliter le suivi du projet. 

1. Vous etudiez la fagon dont l’intranet est utilise sur les autres projets et 
vous definissez les procedures et fonctions les plus utiles pour ameliorer 
l’efficacite du projet. 

2. Vous demandez a un des autres chefs de projet utilisant deja l’intranet de 
faire une presentation devant l’ensemble de l’equipe. Puis vous organisez 
une reunion avec votre equipe pour decider des modalites d’utilisation de 
l’intranet. 

3. Vous chargez un membre experiments de 1’ equipe, avec lequel vous avez 
deja travaille, de mettre en place l’intranet dans un delai d’une semaine et 
de prevoir une information/formation a l’ensemble de l’equipe. 

4. Vous expliquez a l’ensemble de l’equipe l’interet d’utiliser un intranet sur 
le projet et vous constituez un groupe de volontaires pour proposer une 
utilisation. 

13.1.10 Corrige de la mise en place d’un intranet pour le projet 

La qualification des attitudes est donnee a la figure 13.5. 



Style 

Avantages 

Risque ou inconvenients 


Directif apres 
information 

Coherent avec les choix de 
gestion du chef de projet 

Peut etre mat accepte si 
l’equipe n’adhere pas 
pleinement au projet ou si 
P intranet est contraignant. 

2 

Participatif 

groupe 

Facilite l’utilisation ulterieure. 
Corneille 


3 

Par delegation 

Ne disperse pas les energies. 

Risque de rejet par le reste 
de 1’ equipe. 

4 

Persuasif 

+ 

Par delegation 

Responsabilise les volontaires. 

Risque de dispersion de 
l’equipe. 

Risque de retard. 
Deconseille 


Figure 13.5 — Styles de management pour la mise en place d'un intranet pour le projet. 
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Vous etes engages dans les cinq conflits suivants. On vous propose, chaque fois, 
deux comportements a adopter. Indiquez, pour chaque conflit et pour chaque 
comportement propose : 

1. La strategic de resolution correspondante. 

2. Les avantages et les risques de cette strategic. 

13.2.1 Enonce d’un conflit avec le maltre d'ouvrage 

Le projet a commence depuis quatre mois. Un nouveau maitre d’ouvrage vient 
d’etre nomme, en remplacement de celui avec lequel vous avez planifie un deve- 
loppement en spirale, qui a ete appele a d’autres fonctions. 

Le nouveau maitre d’ouvrage remet en question les priorites de planification 
des fonctions, ce qui a des impacts sur le travail en cours et vous oblige en parti- 
culier a revoir votre planification et l’attribution des taches. 

Comportement 1 : Vous evitez le maitre d’ouvrage. Le prochain Comite de 
pilotage a lieu dans un mois. Vous esperez que d’ici la, le maitre d’ouvrage sera 
devenu raisonnable, ou bien que votre directeur informatique se montrera 
intransigeant. 

Comportement 2 : Vous faites le point avec votre equipe. Vous analysez le 
travail deja commence sur les modules a repousser, ainsi que les competences des 
personnes disponibles. Vous acceptez de commencer tres rapidement le module 4 
pour lequel vous disposez des bons profils. En revanche vous ne cedez pas sur le 
module 6 : il sera fait dans la version 2. Le maitre d’ouvrage vous demande 
d’integrer une fonction du module 6 dans le module 4. Vous finissez par accepter 
a contrecoeur. 


13.2.2 Corrige d’un conflit avec le maitre d'ouvrage 

La qualification des strategies est donnee a la figure 13.6. 
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Strategic 

Avantages 

Risques 

■ 

Retrait 

+ 

Force 

Ne pas heurter de front 
le maitre d’ouvrage. 

A terme, pas de relation de 
confiance entre le chef de 
projet et le MOA. 

Risque de replanification in 
extremis si le MOA impose 
son point de vue en Comite 
de pilotage. 

2 

Compromis 

Le chef de projet amorce une 
relation de negotiation 
ouverte avec le MOA. 

L’ equipe est engagee dans la 
recherche d’une solution. 

Le chef de projet a accepte des 
modifications de planification 
qui touchent le decoupage 
en modules : risques sur la 
qualite. 


Figure 13.6 — Strategies face a un conflit avec le maTtre d’ouvrage. 


13.2.3 Enonce d’un conflit avec le responsable qualite 

Vous allez bientot terminer l’analyse du projet. Vous avez utilise differents 
modeles pour representer la partie statique et la partie dynamique des traite- 
ments. Le responsable qualite vient de mettre en vigueur de nouvelles procedu- 
res d’assurance qualite : il vous demande de rajouter dans votre dossier d’ analyse 
les modeles correspondant a la description des traitements sans les choix d’orga- 
nisation, ce que vous trouvez superflu. 

Comportement 1 : Vous rencontrez le responsable qualite. Vous le questionnez 
sur les nouvelles procedures, vous lui montrez qu’elles vont dans le sens de vos 
pratiques, comme en temoigne le PAQ de votre projet. Vous arrivez a le 
convaincre que les modeles supplementaires seront rajoutes apres la livraison du 
dossier d’analyse. 

Comportement 2 : Vous organisez une reunion avec le responsable qualite et 
toute votre equipe. Vous demandez au responsable qualite d’exposer les principes 
et le contenu des nouvelles procedures. Vous recberchez ensemble une solution 
a moindre cout pour mettre a niveau les dossiers. 


13.2.4 Corrige d’un conflit avec le responsable qualite 

La qualification des strategies est donnee a la figure 13.7. 
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Strategic 

Avantages 

Risques 

1 

Apaisement 

+ 

Compromis 

Le chef de projet preserve ses 
engagements. 

Pas de conflit ouvert : l’equipe 
peut continuer a travailler 

Le probleme est renvoye apres 
la livraison : s’il n’est pas 
traite, risque d’ augmentation 
du conflit. 

2 

Collaboration 

Etablissement de bonnes 
relations avec le responsable 
qualite. 

Risque de derive du projet, 
dont le chef de projet sera tenu 
pour responsable. 


Figure 1 3.7 — Strategies face a un conflit avec le responsable qualite. 


13.2.5 Enonce d’un conflit avec un autre chef de projet 

Bernard est affecte a temps partiel sur votre projet, et a 50 % sur un projet de 
Datawarehouse qui doit se terminer dans un mois. Le partage se fait par demi- 
semaine. L’ autre projet a pris du retard et depuis deux semaines, Bernard n’a 
travaille que deux jours sur votre projet (au lieu de 5). 

Comportement 1 : Vous esperez que cela va aller mieux a Tissue du projet 
Datawarehouse. 

Comportement 2 : Vous allez voir votre maitre d’ouvrage. Vous lui exposez la 
derive dans laquelle le projet risque de s’engager. Vous obtenez de lui qu’il inter- 
vienne aupres du directeur informatique pour que Bernard intervienne confor- 
mement aux engagements ou bien qu’il soit remplace. 


13.2.6 Corrige d’un conflit avec un autre chef de projet 

La qualification des strategies est donnee a la figure 13.8. 



Strategic 

Avantages 

Risques 

1 

Retrait 

Pas de conflit entre collegues. 

Le probleme peut ne pas 
s’ arranger si rapidement et le 
projet va prendre un retard 
important. 

2 

Force 

Le conflit se fait par personnes 
interposees. 

Le conflit risque d’augmenter 
si la ressource est retiree de 
1’ autre projet. 


Figure 1 3.8 — Strategies face a un conflit avec un autre chef de projet. 
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13.2.7 Enonce d’un conflit avec le responsable technique 

Vous avez commence l’etude technique, et le responsable technique attache a la 
Direction informatique vous annonce que tous les projets qui devaient etre 
developpes dans un environnement Windows NT4 doivent maintenant se faire 
dans l’environnement Windows NT5. II vous assure que cela ne posera pas de 
problemes. 

Comportement 1 : Vous allez voir le directeur informatique et lui exposez les 
risques et perturbations generes. Vous obtenez une ressource support a mi-temps 
pendant un mois pour aider votre equipe a faire le passage. 

Comportement 2 : Vous annoncez a votre equipe que votre projet n’est pas 
conceme par le changement d’environnement. Parallelement, vous essayez de 
negocier le report du changement pour la version 2. 

13.2.8 Corrige d’un conflit avec le responsable technique 

La qualification des strategies est donnee a la figure 13.9. 



Strategic 

Avantages 

Risques 

■ 

Force 

+ 

Compromis 

Le chef de projet se decharge 
de la responsabilite d’un 
retard. 

Le chef de projet preserve ses 
relations avec le responsable 
technique. 

La charge de support a mal ete 
evaluee. 

2 

Retrait 

+ 

Compromis 

L’ equipe est tenue a distance 
des perturbations. 

Le projet n’est pas impacte 
directement. 

La negotiation peut echouer. 
Le changement de systeme 
peut etre impose par la direc- 
tion et perturber fortement le 
projet. 


Figure 13.9 — Strategies face a un conflit avec le responsable technique. 


13.2.9 Enonce d’un conflit avec le chef de projet utilisateur 

Vous avez commence 1’ etude technique, et le responsable technique Le chef de 
projet a organise, a votre insu, une reunion avec les utilisateurs, au cours de 
laquelle certaines options de conception ont ete discutees et legerement modi- 
fiees. Vous n’avez pas apprecie lorsque vous l’avez appris. 

Comportement 1 : Apres quelques jours de reflexion, vous rencontrez le chef 
de projet utilisateur et vous essayez de comprendre les raisons de sa demarche, 
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ainsi que la pertinence des modifications apportees. Vous les annoncez ensemble 
a l’ensemble de l’equipe. 

Comportement 2 : Vous jugez les changements peu importants. Pour le prim 
cipe, vous n’en acceptez que la moitie, en invoquant diverses raisons techniques. 


13.2.10 Corrige d’un conflit avec le chef de projet utilisateur 

La qualification des strategies est donnee a la figure 13.10. 



Strategic 

Avantages 

Risques 

1 

Retrait 

+ 

Collaboration 

Preservation des relations avec 
le chef de projet utilisateur. 

Le chef de projet utilisateur 
risque de faire a nouveau 
cavalier seul. 

2 

Compromis 

Message envoye au chef de 
projet utilisateur : les initiati- 
ves individuelles ne doivent 
pas se prendre au detriment du 
travail d’equipe. 

Le chef de projet utilisateur est 
insatisfait et la relation se 
degrade. 


Fisure 13.10 — Stratesies face a un conflit avec le chef de projet utilisateur. 
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Le plan qualite 
d’un projet 


14.1 LECASMECANO 

Le cas Mecano a ete presente au chapitre 9. Nous en etudions ici les aspects 
concernant la maitrise de la qualite. 

Vous ferez un certain nombre d’hypotheses et proposerez un plan qualite. 
Vous distinguerez deux parties : 

1. La qualite souhaitee du futur systeme a l’aide des facteurs et criteres 
qualite. 

2. Les dispositions preconisees pour donner a votre client l’assurance de la 
qualite du processus que vous allez conduire. 

Vous prendrez comme base la strategic adoptee suite a l’analyse du projet et 
de ses risques, qui figure au paragraphe 9.1.5. Votre plan qualite peut etre struc- 
ture en deux parties. 

• Premiere partie : la qualite du produit 

Cette partie est faite en liaison etroite avec le client. Elle lui permet d’expli- 
citer les caracteristiques sur lesquelles il jugera l’application. Vous choisirez 
parmi les facteurs et criteres de Boehm-McCall ceux qui vous paraissent 
pertinents et vraisemblables dans le contexte du projet. Leur nombre doit 
etre limite et ils ne doivent pas etre contradictoires. 
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• Deuxieme partie : la qualite du processus 

Cette deuxieme partie, liee au plan de management de projet, comprendra les 
elements suivants : 

- responsabilites qualite ; 

- documents de reference ; 

- organisation ; 

- demarche de developpement ; 

- document de suivi de projet ; 

- plan de controle ; 

- mise en oeuvre. 

14.2 CORRIGE DU PLAN QUALITE DU CAS MECANO 


Un exemple de plan qualite pour le projet Mecano est donne ci-dessous. 

14.2.1 Premiere partie : la qualite du produit 

L’ application MAO doit d’une part ameliorer l’efficience de la fonction mainte- 
nance, d’ autre part favoriser une diminution des temps de panne. 

Nous attendons qu’elle satisfasse aux exigences qualite suivantes. 

D’un point de vue fonctionnel, l’application doit etre pertinente, c’est-a-dire 
qu’elle doit etre adaptee a la taille de l’entreprise. Son perimetre doit etre limite aux 
fonctions de base des deux processus Suivi d’intervention et Aide a l’intervention. 

Le premier comprendra les fonctions suivantes : 

• demande d’intervention ; 

• planification des interventions ; 

• suivi des interventions en cours ; 

• solde d’une intervention ; 

• statistiques. 

Le second se compose egalement de cinq fonctions : 

• gestion des nomenclatures des machines ; 

• gestion des plans ; 

• gestion des gammes operatoires ; 
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• gestion des outillages ; 

• aide a la recherche de pieces. 

Les metriques retenues pour ce facteur mesurent la diminution des temps 
d’intervention. 

Le delai avant intervention est actuellement de deux heures, il doit etre 
ramene a une heure pour 95 % des interventions. Le gain sera obtenu par un 
circuit d’information court entre la production et la maintenance, ainsi que par 
une planification rigoureuse des interventions. 

La duree moyenne d’intervention est de trois heures ; elle doit etre reduite a 
deux heures et demie dans 95 % des cas, sauf indisponibilite des pieces. Le gain 
sera possible par Faeces aise aux informations sur les machines, les outillages et 
les gammes operatoires, ainsi que par la disponibilite immediate des plans. 

L’application doit etre adequate, e’est-a-dire qu’elle doit s’adapter aux procedu- 
res existantes, dont elle doit augmenter la fluidite. Toutes les decisions sur les 
operations de maintenance a mener sont, comme actuellement, du ressort de 
l’ouvrier de maintenance. On ne souhaite pas renforcer la centralisation des deci- 
sions, ni augmenter leur degre d’automatisation. Au contraire, les informations 
communes doivent etre partageables. Les communications entre production et 
maintenance doivent etre facilities le plus possible. Seules sont centralisees la 
gestion des donnees de reference stables et la planification des interventions. 

La mesure de Fatteinte de ce facteur sera la proximite des modeles organisa- 
tionnels de traitements entre Fancien et le nouveau systeme. 

D’un point de vue utilisation, Fapplication doit etre maniable. Les utilisateurs 
au quotidien sont principalement des ouvriers. Le vocabulaire manipule dans les 
interfaces homme-machine doit etre celui qui est utilise couramment. 

Les deux criteres souhaites sont la communicabilite et la facilite d’apprentissage. 
Le premier porte sur Finterface utilisateur, qui doit etre tres simple d’usage. La 
metrique sera une mesure d’opinion : un echantillon representatif d’utilisateurs 
finaux, utilisant Fapplication depuis deux mois, sera interroge. Le deuxieme 
critere sera mesure par le temps d’apprentissage de la manipulation de Fapplica- 
tion : il ne devra pas depasser une demi-joumee pour les ouvriers comme pour les 
cadres. 

La confidentialite de Fapplication doit etre assuree de deux fagons. Les 
donnees de references sont mises a jour par un responsable unique. Les donnees 
concemant une intervention ne sont pas modifiables a posteriori, dans le sens 
que toutes les rectifications sont enregistrees sans effacer les donnees initiales. 
Ce facteur sera mesure par des tests utilisateurs. 
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L’ application devra etre couplee avec trois applications. Elle se servira des 
donnees de l’application Personnel pour l’identification des differents interve- 
nants sur une operation de maintenance. Elle alimentera sans nouvelle saisie 
l’application de comptabilite analytique. Elle pourra interroger la gestion des 
stocks, effectuer des reservations et si necessaire declencher une commande 
urgente. L’arrivee des pieces commandees doit donner lieu a un signal dans le 
module planification des interventions. L’atteinte de ce facteur sera mesuree par 
des tests de recette. 

14.2.2 Deuxieme partie : la qualite du processus 

En ce qui conceme les responsabilites qualite, le chef de projet jouera le role de 
responsable qualite sur le projet. Les differents modules feront l’objet d’une 
qualification par la section qualite du service informatique. Le client est respon- 
sable de la qualite des jeux d’essais de recette. 

Les documents de reference sont les suivants. Le plan de management de projet 
a ete decrit dans le document MAO-2. L’application respectera les normes de 
presentation de l’interface utilisateur decrites dans le document INF95-34. La 
documentation de l’application sera semblable a celle de l’application Gestion 
des stocks mise en service Pan dernier : GS16. Le manuel utilisateur sera reduit 
au minimum et remplace par une aide en ligne, conformement a la norme 
interne INF92-8. 

Pour ce qui est de 1 ’organisation, l’equipe de projet comprendra quatre per- 
sonnes en tout : MM. Alain, Jean et Bon du service informatique, ainsi que 
M me Legrand du service maintenance. 

M. Alain sera chef de projet. MM. Jean et Bon seront concepteurs-deve- 
loppeurs. Le premier sera specialise sur l’utilisation du multimedia pour la 
gestion des plans. Le second sera specialiste de la base de donnees objet. Tous 
deux feront a la fois de la conception et du developpement. M me Legrand sera 
affectee a temps plein sur le projet pendant l’etape de conception generale et a 
mi-temps ensuite. 

Le developpement des modules comprendra des phases d’experimentation 
d’une duree de cinq jours ouvrables. Les deux concepteurs-developpeurs se tien- 
dront a disposition des utilisateurs temoins pour leur apporter de l’aide s’ils le 
souhaitent. La liste des participants a l’experimentation sera composee de la 
fagon suivante : 

• service maintenance : cinq personnes ; 

• production chaine A : cinq personnes ; 

• production chaine B : cinq personnes. 


14.2. Corrige du plan qualite du cas Mecano 


g 


II est a noter que ces trois chames ont ete choisies, en fonction des contrain- 
tes de production. Si ces demieres changeaient, le client pourrait mettre a dispo- 
sition des personnes choisies dans une autre chame. 

La demarche de developpement a ete decrite dans le plan de management de 
projet (voir paragraphe 9.1.6). Celui-ci donnera lieu a la livraison des foumitu- 
res mentionnees a la figure 14.1. 


Point de livraison 

Contenu de la fourniture 

Validation 

Fin de l’etape de conception 
generale 

Rapport de conception : 

- architecture materielle 

- architecture logicielle 

- modele de donnees avec le forma- 
lisme entite/relation 

- modeles organisationnels de traite- 
ment (MOT) 

Comite 
de pilotage 

Fin de la phase prototypage 
de chaque cycle de realisa- 
tion 

Prototype installe sur trois postes en 
fibre service dans la salle B202 



Figure 14.1 — Livraison des fournitures dans le projet Mecano. 


Le planning des premieres etapes, c’est-a-dire jusqu’a la livraison du premier 
module figure en annexe. II sera complete par le calendrier de developpement 
des modules 2 et 3, a la fin de la conception generale. 

Le document de suivi de projet est structure selon le modele de la figure 14.2, 
avec les indicateurs suivants : 

Evolution de charge pour le mois ecoule = temps passe - avancement 

Evolution de charge en jours depuis le debut du projet = 
temps passe + reste a faire a ce jour - charge initiale. 

Evolution de charge depuis le debut du projet en pourcentage = 
evolution de charge en jours x 100/charge initiale. 

Achevement en pourcentage = 

(Charge initiale - reste a faire a ce jour) x 100/charge initiale 

II sera fourni tous les lundis matins par le chef de projet au client. II donnera 
lieu a une mini-reunion d’une demi-heure. 


a 


14. Le plan qualite d'un projet 


Tableau d’avancement du projet : nom en fin de mois : mois 


Mois n-1 

Mois n 

Recapitulate projet 

Lots 

Temps passe 

Reste a faire 

Temps passe 

Reste a faire 

Avancement 

Evolution de charge 

Charge initiale 

Temps passe 

Evolution en jours 

Evolution en % 

Achevement en % 






































Fisure 14.2 — Document de suivi du projet Mecano. 


Le plan de controle comporte trois volets : 

• Le chef de projet fera une verification systematique et complete de tous 
les produits livres : etudes, programmes et documentation. 

• Les programmes du premier prototype feront l’objet d’une lecture croisee 
prealable a sa mise a disposition. 

• Le client fournira les jeux d’essais de recette qui seront utilises lors de la 
production du logiciel. 

La mise en oeuvre sera pilotee par M me Legrand. Elle fera l’objet d’un plan 
assurance qualite separe. 

Ce plan qualite engage le maitre d’oeuvre et le maitre d’ouvrage. Toute evolu- 
tion souhaitee par l’une ou l’autre partie devra etre negociee et donnera lieu, en 
cas d’ accord, a une nouvelle version. 
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Un excmplc d’utilisation 
de Microsoft Project 


15.1 LE CAS PARKING 

Nous allons reprendre l’enonce du cas Parking figurant au chapitre 12, qui a 
permis de simuler le deroulement d’un petit projet. II va nous servir a donner un 
exemple de systeme d’information de pilotage a partir de l’outil Microsoft® 
Project 2003. Nous n’avons pas cherche a reproduire les indicateurs presentes au 
chapitre 7 et illustres au chapitre 12, qui sont destines a un suivi avec un tableur 
comme Excel, mais nous proposons un choix parmi ceux proposes par MS Project 
et nous indiquerons les correspondances. 

Le projet se deroule en Pan 2006 et commence debut janvier. Toutes les 
contraintes de calendriers et de ressources sont identiques a celles qui figurent au 
chapitre 12 (paragraphe 12.1). 


15.2 INITIALISATION DU PROJET PARKING 

15.2.1 Creation du projet Parking 

On va pour commencer, indiquer ses caracteristiques generales : Projet, Infor- 
mations sur le projet... On saisit la Date de debut : 2/1/06, et on selectionne 
« Previsions a partir de » : Date de debut du projet. 
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On sauvegarde le projet par Fichier, Enregistrer sous : Parking, mpp, 

Puis, dans Fichier, Proprietes, onglet ‘Resume’, on saisit le Sujet et le nom 
de l’Auteur. 


15.2.2 Choix des options du projet Parking 

On selectionne les options de planification par Outils, Op tions... 

Onglet Affichage 

On choisit d’afficher une tache recapitulative du projet, precedee d’un symbole, 
et en decalant vers la droite les autres taches par « Abaisser le nom ». On va par 
ailleurs gerer les couts de notre projet en Euros. 
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Onglet Calendrier 

On table sur une semaine de 35 heures reparties uniformement sur 5 jours. 



Onglet Previsions 

Le type de tache par defaut Capacite fixe signifie que l’information « Duree », 
saisie lors de la planification des taches, est en fait une quantite de travail — 
c’est-a-dire une charge — et que la duree de la tache pourra etre modifiee par 
MS Project en fonction du nombre de personnes affectees. 

Le pilotage par Peffort signifie que le suivi s’effectuera a partir des comptes 
rendus d’avancement des ressources affectees au projet. Dans le cas contraire, on 
saisirait directement les donnees d’avancement d’une tache, sans passer par les 
ressources. Pour des projets principalement bases sur du travail intellectuel, il est 
conseille de suivre le travail de chaque intervenant dans l’equipe de projet. 

Onglet Calcul 

Par Calcul Automatique, on choisit de laisser MS Project declencher le calcul 
de la planification ou de l’avancement du projet des la saisie de nouvelles infor- 
mations. De meme, les couts reels, que l’on sous-entend proportionnels aux 
ressources utilisees, seront calcules automatiquement a la saisie de l’avancement. 


0 
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Onglet Previsions 



Onglet Calcul 
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15.2.3 Definition du calendrier du projet Parking 

On modifie le calendrier par Outils, Modifier le temps de travail... On selec- 
tionne du lundi au vendredi (L a V) et on modifie les horaires de travail de fagon 
a avoir des demi-joumees de meme duree (3 h 30). 



On va ensuite indiquer les deux jours feries, vendredi saint et lundi de Paques, 
soitles 17 et 20 mars. 


153 PLANIFICATION DU PROJET PARKING 

15.3.1 Saisie des taches du projet Parking 


La saisie se fait par Affichage, Diagramme de Gantt avec le choix complemen- 
taire Table : Entree. 
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On saisit la liste des taches et leurs durees, telle qu’elles figurent ci-dessous, 
ainsi que les taches de type jalon (Debut et Fin) avec une duree nulle. On 
obtient le tableau suivant, avec en tete une tache recapitulative, la tache 0, qui 
a ete inseree automatiquement avec la duree de la tache la plus longue, soit 
30 jours conformement a l’option d’affichage choisie precedemment. 




o Norr de la tache 

JureeJ 

fella 


B Parkiny 

30 joins 

Calendrw 


Debut 

Ojour 

Cl 


Parking JE 

Sjours 



Parking ET 

3 jours 



Parking PGM 




Parking TEST 


n 


Vertcule ET 

2 jours! 



Vehicute PGM 

15 jours 



Vehicute TEST 

1.5 jours 

Hi 


Autorisertion JE 

8 jours 



Automation ET 

2 jours j 

des taches 

BE 

— 

Autorisation PGM 
Autorisation TEST 

2fi jours 

m 

\m 

Edtion JE 

3 jours 

Utilisation 


Edllon ET 

1 .5 Jours 

des taches 


Edlion PGM 

IS jours 

PTi 


Edtion TEST 

1j5 jours 



Integration 

10 jours 

Graphe 


Fin 

Ojour 

ressources 
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15.3.2 Saisie des liens du projet Parking 

Pour saisir les liens entre taches, on ouvre d’abord une boite de detail en bas de 
1’ecran par Fenetre, Fractionner. Puis, on se positionne sur une tache et on indique 
toutes les taches qui la precedent directement. 



On saisit les liens tels qu’ils figurent dans le graphe des antecedents ci-dessous : 
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On peut constater que la tache recapitulative du projet a ete mise a jour et 
que la duree du chemin le plus long — en temps travaille, c’est-a-dire hors jours 
chomes — est de 45 jours. 



Nom de la tache 

Duree 

^ 1 

Rn jpredecesseurs 

- 

B Parking 

45 jours 

Lull 02/01/06 

Ven 03/03/06 


Debut 

0 jour 

Lun 02/01/06 

Lun 02/01/06 


Parking JE 

6 jours 

Lun 02/01 J06 

Lun 09/01 .'06 1 


Parking ET 

3 jours 

Lun 02/01 JD6 

Mer 04/01 .'06 1 


Parking PGM 

30 jours 

Jeu 05/01 J06| 

Mer 15/02/06 j3 


Parking TEST 

2 jours 

■Jeu 1 6/02/06 

Ven 1 7/02/06 2;4 


Vehicule ET 

2 jours 

Lun 02/01 JOS 

Mar 03/01/06 1 


Vehicule PGM 

IS jours 

Mer 04/01/06 

Mar 24/01/06 6 


Vehicule TEST 

1 ,5 jours 

Mer 25/01/06 

Jeu 26/01/06 7;9 


Autorisation JE 

8 jours 

Lun 02/01/36 

Mer 11/01/06 1 


Autorisation ET 

2 jours 

Lun 02/01/36 

Mar 03/01/06 1 


Autorisation PGM 

25 jours 

Mer 04/01/06 

Mar 07702/06 10 


Autorisation TEST 

2,5 jours 

Mer 084)2/06 

Ven 1 0/02/06| 9;11 


Edition JE 

3 jours 

Lun 02/01/06 

Mer 04/01 4)6 1 1 


Edition ET 

1,5 jours 

Lun 02/01/06 

Mar 03/01/06 1 


Edition PGM 

IS jours 

Mar 03/01/06 

Mar 24/01/06 14 


Edition TEST 

1,5 jours 

Mar 24/01/06 

Mer 25/0j/06|l3;15 


Integration 

10 jours 

Lun 20/02/06 1 

Ven 03/03/06 5;8;1 2; 16 


Fin 

0 jour 

Ven 03/03/06 

Ven 03/03/06 1 7 







Si Ton affiche l’ensemble du diagramme reseau (Affichage, Organigramme 
des taches) par Affichage, Zoom... avec le choix Ensemble du projet, MS 
Projet organise automatiquement la disposition des taches. 

Cependant en selectionnant dans Format, Disposition, Mode de disposi- 
tion, « Positionnement manuel des cases » on peut deplacer manuellement les 
taches puis aligner les cases par Format, Reorganiser maintenant. On peut en 
modifier le style des liaisons entre les taches par Format, Disposition, « Styles 
des liaisons ». 

Les champs Debut et Fin correspondent aux dates au plus tot. Par Format, 
Style de case, Plus de modeles, on peut choisir les champs a afficher dans le 
graphique. On peut par exemple remplacer le N° par la marge totale. 

On obtient le reseau ci-contre. 

On peut verifier sur l’ecran que les marges totales affichees sont bien egales a 
celles du diagramme ci-dessous. 



Parking ET | J Parking PGM 


15.3. Planification du projet Parkins 


0 




Edition ET I ^ I Edition PGM 






ill 
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1533 Saisie et affectation des ressources du projet Parking 

On cree nos trois ressources Claude, Camille et Boss (le chef de projet) et on 
indique leur cout horaire (respectivement 50, 80 et 150 Euros) par Affichage, 
Tableau des ressources, avec le choix Table : Entree. Ce qui nous donne : 


~T“” - 1 





Tx. standard 


CoiMJffleatim 

"1 

“1 

| 

1 tZ! — 











1 1 r - 


BO 


— 

I50 0DC, 


— ^ 

PiupurlOn | 




On indique l’attribution des lots Parking et Edition a Claude, tandis que 
Camille fera les lots Vehicule et Autorisation, ainsi que l’Integration. Pour cela, 
on utilise Affichage, Diagramme de Gantt, avec le choix Table : Entree. On 
selectionne les taches a affecter (en utilisant la touche Ctrl si les taches ne sont 
pas contigues), puis on clique sur l’icone d’affectation en haut a droite de l’ecran 
et on choisit la ressource. 



On aurait pu utiliser egalement Outils, Ressources, Affectation des ressources. . . 

Si l’on regarde le diagramme de Gantt, on voit que l’execution des taches a 
ete planifiee par MS Project sans tenir compte de la surutilisation des ressources. 
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Le detail des surutilisations est donne par Affichage, Utilisation des ressources, 
avec le choix Table : Resume. 

Si Ton conserve uniquement les colonnes qui nous interessent et que l’on 
filtre l’affichage par Projet, Filtre pour : Ressources surutilisees, on obtient le 
tableau recapitulatif ci-dessous. Claude et Camille sont par moments charges 
respectivement jusqu’a 400 et 300 % ! 


H 

z 

Nom de la ressource 

3 

Capacite 

B 

Tx. standard 

ml 

Cout 

t£J 


FI Claude 


inn% 

400% 

50,110 #/hr 

0,00 tihw 1 

21 700,00 # 1 

6? jours 



ffl Camille 


100% 

300% 

80,00 ttir 

0,00 €/hr 

36 960,00 € 

66 jours 









1 



Les jours de surutilisation peuvent etre visualises avec la commande Format, 
Details et le choix Surutilisation. 

Pour supprimer la surutilisation, nous devons decider de l’ordre dans lequel 
chacun effectuera les taches (cf. ci-dessous). Ensuite, le plus simple est d’intro- 
duire les modifications dans les caracteristiques des taches, en changeant les 
predecesseurs. Cela revient a effectuer un nivellement manuel. 

On modifie la duree de la tache ‘Parking JE’puisque Ton a attribue 8 jours a 
Claude. MS Project ne gere pas la notion de charge affectee. On peut conserver 
l’estimation standard (6 jours) en commentaire de la tache. 

La saisie des nouvelles donnees peut se faire directement dans la table Entree 
du Diagramme de Gantt. Le nivellement effectue ici se resume a la modification 
des predecesseurs des taches. Vous observerez que les dates sont automatiquement 
changees. 

Apres modifications , la nouvelle liste est la suivante : 


H 

Calendrier 

m 

Diagramme 
de Gantt 

m 


m 

Orgaiigramnr 
des taches 

m 

Utilisation 
des taches 

m 




Fin Predecesseurs Nome ressources 


s Parking 

74 jours 

Lun 02/01/06 

Lun 17/04/06 


Debut 

0 jour 

Lun 02 j01/06 

Lun 02*1*6 


Parking JE 

r 8 jours 

Lun 02*1*6 

Mer 11*1*6 1 

Claude 


Parking ET 

3 Jours 

Jeu 12*1 *6 

LurTl 6/01*6 2 

Claude 


Parking PGM 

30 Jours 

Mar 1 7X31 *6 

Lun 27/02*6 3 

Claude 


Parking TEST 

2 jours 

Mar 20*2*G 

Mer 31 *3*6 4 

Claude 


Vehicule ET 

2 Jours 

Jeu 12*1 *6 

Ven 13*1*6 9 

Camille 


Vehicule PGM 

1 S jours 

Lun 16*1/06 

Ven 33*2*6 6 

Camille 


Vehicule TEST 

1 ,5 jours 

Lun 06*2/06 

Mar 37*2*6 [7 

Camille 


Autorisation JE 

8 jours 

Lun 02/01/06 

Mer 11*1*6 1 

Camille 


Autorisation ET 

2 jours 

Mar 07*2/06 

Jeu 39*2*6 8 

Camilla 


Autorisation PGM 

25 jours 

Jew 09/02/06 

Jeu 1 6*3*E 10 

Camille 


Autorisation TEST 

2,5 jours 

.leu 1 6*3*6 

Mer 11 Camile 


Editbn JE 

3 jours 

Jeu 02*3/06 

Lun D6*3*E 5 

Claude 


Edition ET 

1 ,5 jours 

Mar 07*3*6 

Mer 38*3*6 13 

Claude 


Edition PGM 

1 5 jours 

Mer 08/03/06 

Ven31/03iOE 14 Claude 


Edition TEST 

1,5 jours 

Ven 31 *3*6 

Lun Q3*4*E 1 1 5 

Claude 


Integration 

10 jours 

Mar 04*4*6 

Lun 17*4*6 12;1B 

Camille 


Fin 

0 jour 

Lun 1 7*4*6 

Lun 17*4*6 17 


1 , 1 1 
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On va ensuite rechercher la periode ou Camille pourra prendre ses conges. 

On peut utiliser le graphe des ressources par : Affichage, Tableau des ressources ; 
on selectionne Camille, puis Affichage, Graphe ressources ; on voit, apres avoir 
choisi par Format, Echelle de temps... un format adequat, qu’entre le 23 mars et 
le 3 avril compris, Camille n’est pas utilisee. 

On peut alors modifier son calendrier pour planifier son absence par Outils, 
Modifier le temps de travail... pour Camille. 



Pour visualiser le Gantt definitif sur une seule page ecran, on peut reduire la 
hauteur des lignes en selectionnant l’ensemble des lignes et en ajustant avec le 
pointeur la hauteur de n’importe quelle cellule situee dans la premiere colonne : 


I 17 

Integration 

10 jours 

Mar 04*04/06 


Fin 

□ jour 

Lun 17/04/06 



EBEEEEBEEEEEEEEEEEEE 


7 5.3. Planification du projet Parkins 
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On peut obtenir le cout du projet resultant de l’utilisation prevue de Claude 
et Camille par Affichage, Diagramme de Gantt et Table :_Cout. II est de 
59 360 euros qui se repartissent ainsi : 



15.3 A Memorisation du planifie pour le projet Parking 

Maintenant, nous sommes satisfaits du planning, nous allons done enregistrer 
la planification comme planification initiale. Pour ce faire : Outils, Suivi, 
Enregistrer la planification initiale. . . : 
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On selectionne, « Enregistrer la planification initiale » pour « Ensemble du 
projet ». 

Apres validation, nous pouvons constater que le cout total du projet est egal 
au planifie et que la variation est a 0.00 €. 


| i i b bbb bi narnam i ; ; I 
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15.4 PILOTAGE DU PROJET PARKING 

15.4.1 Saisie de I'avancement du projet Parking a la fin janvier 

Pour alleger notre illustration, nous allons effectuer la saisie des comptes rendus 
d’avancement non pas a la fin de chaque semaine, mais en fin de mois. On 
commence par modifier la date du jour par Projet, Informations sur le projet... : 
on se positionne au 1/2/06 (Date actuelle). 

On utilise la grille de saisie donnee par Affichage, Gantt suivi. On va person- 
naliser la table utilisee par Table : Plus de tables... On copie la table Suivi que 
l’on va ajuster : 
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On appelle la nouvelle table Avancement. Elle contient les cinq champs 
suivants : N°, Nom, Debut reel, Fin reelle et Travail restant (reste a faire). II faut 
egalement renseigner les Titres des colonnes et cocher la case « Visible dans le 
menu ». Puis OK et Appliquer. 



Ensuite on ajuste les echelles de temps par Format, Echelle de temps... de 
fagon a avoir une colonne par jour. Par exemple, au niveau intermediaire on 
choisit la Semaine et au niveau inferieur le Jour (on peut egalement modifier les 

Etiquettes) : 



15.4. Pilotage du projet Parking 


a 



On definit une fenetre permettant de saisir le travail effectue quotidienne- 
ment par Fenetre, Fractionner. On clique dans la fenetre du bas et on selec- 
tionne Affichage, Utilisation des ressources avec Table : Utilisation. 

En cliquant sur la tache ParkingJE de la fenetre du haut, on voit apparaitre 
toutes les taches de la ressource Claude. 

On se positionne alors dans le calendrier en bas a droite et on clique avec le 
bouton droit de la souris ; on peut selectionner ce que Ton veut saisir : le Travail reel 
(verifier une deuxieme fois avec le bouton droit que seul « Travail reel » est coche ! ). 



On va maintenant saisir les jours de travail reels des ressources sur chaque 
tache du mois de janvier (d’apres les comptes rendus d’avancement donnes plus 
bas), de la fagon suivante : 

• on se positionne dans le tableau en bas a gauche sur la tache sur laquelle 
la ressource a travaille ; 

• on indique les journees ou demi-joumees travaillees en tapant 1 ou 0,5 
dans les cellules correspondant aux jours du calendrier, en bas a droite : la 





a 


75. Un exemple d’utilisation de Microsoft Project 


date de debut reel du tableau en haut a gauche est automatiquement 
renseignee ; 

• si la tache est terminee (reste a faire = 0), on saisit la date de fin reelle sur le 
tableau en haut a gauche ; 

• si la tache n’ est pas terminee a la fin du mois et que le reste a faire est diffe- 
rent de celui qui a ete calcule par MS Project et qui figure dans le champ 
Travail restant du tableau en haut a gauche, on saisit le reste a faire indiquer 
dans le compte-rendu d’avancement. 



On saisit successivement l’avancement de Claude et Camille pour le mois de 
janvier, selon les elements de leurs comptes rendus hebdomadaires, donnes ci- 
dessous. 


Claude 

2/1 

3/1 

4/1 

5/1 

6/1 

Reste a faire 

Parking JE 

1 

1 

0,5 

1 

0,5 

4 


9/1 

10/1 

11/1 

12/1 

13/1 

Reste a faire 

Parking JE 

1 

1 

1 

1 

1 

0 


16/1 

17/1 

18/1 

19/1 

20/1 

Reste a faire 

Parking ET 

1 

1 

1 



0 

Parking PGM 




1 

1 

28 


23/1 

24/1 

25/1 

26/1 

27/1 

Reste a faire 

Parking PGM 

1 

1 

1 

1 


24 
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30/1 

31/1 




Reste a faire 

Parking PGM 

1 

1 




22 


Camille 

2/1 

3/1 

4/1 

5/1 

6/1 

Reste a faire 

Autorisation JE 

1 

1 

1 

1 

1 

0 


9/1 

10/1 

11/1 

12/1 

13/1 

Reste a faire 

Vehicule ET 

1 

1 




0 

Vehicule PGM 



1 

1 

1 

13 


16/1 

17/1 

18/1 

19/1 

20/1 


Maladie 








23/1 

24/1 

25/1 

26/1 

27/1 

Reste a faire 

Vehicule PGM 

1 

1 

1 

1 

1 

8 


30/1 

31/1 




Reste a faire 

Vehicule PGM 

1 

1 




2 


15 A. 2 Recapitulate de I'avancement du projet Parking a la fin janvier 

On va preparer un tableau synthetique de I’avancement mensuel. 

On supprime le fractionnement par Fenetre, Supprimer le fractionnement 
et on selectionne Affichage, Gantt suivi, avec Table : Plus de tables... 

On copie la table Suivi que Ton va ajuster en la renommant Recapitulatif, 
avec dans l’ordre les quatorze champs suivants, qui permettent de suivre la 
production et les ecarts par rapport au planifie : 

N°, Initiales de la ressource, Nom, % Travail acheve, Travail reel, Travail 
restant, Travail planifie, Variation de travail, Debut reel, Debut planifie, Variation 
date de debut, Fin reelle, Fin planifiee, Variation date de fin. 

Pour faciliter le suivi, on va modifier l’affichage en triant et en filtrant les 
donnees, de la fagon suivante. 

Pour presenter ce tableau par intervenant, on utilise Projet, Trier, Trier 
par... en choisissant Initiales de la ressource comme premier critere de tri 
(decroissant) et N° comme second critere de tri (croissant). 

Pour n’afficher que les taches qui ont ete actives en janvier, c’est-a-dire ayant 
une date de debut reel, on utilise Projet, Filtre pour : Plus de filtres... et on 
cree un nouveau filtre que Ton appelle Recapitulatif et qui contient la condition 
suivante : 
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Nom : |Rscapilulatif F Afficher dans le menu 

Fire : 







Couper | Copier | 'i' 

| Inserer | iuppriner | 




A 

Et/ou Nom du champ 

Conditbr 

Valeur(s) 

■r| Debut reel 

Different de 

NC 


On applique le filtre et on obtient le tableau de bord suivant, ou Ton peut 
suivre les consommations en charge : 


N" 

Intt. Ress. | Nom de la tache 

i 

i 

Trav.R«l 

Trav, Rest ant 

Trav .Ptanif ie 

Var.Travail 

0 

E Parking 

30% 

37 joure 

88 joure 

130 jours 

5 jours 

2 

CL Parking JE 

100% 

9 jours 

Ojour 

8 jours 

1 jour 

3 

CL Parking ET 

100% 

3 jours 

Ojour 

3 jours 

Ojour 

* 

CL Parking PGM 

27% 

8 jours 

22 jours 

30 jours 

Ojour 

6 

CA Vehicule ET 

100% 

2 jours 

Ojour 

2 jours 

Ojour 

J 

CA Vehicule PGM 

83% 

10 jours 

2 jours 

15 jours 

-3 jours 

9 

CA Autorisation JE 

100% 

5 jours 

Ojour 

8 jours 

-3 jours 


Si Ton regarde les colonnes les plus a droite, on voit que le projet a 
commence a la date prevue, mais a pris trois jours de retard global par rapport a 
la fin planifiee : 


N“ 

Debut reel 

Debut planilie 

Var.DD£but 

Fin reelle 

Fin planifiee 

Variation b.Fin 

a ] 

Lun 02/01/06 

Lun 02/01/06 

Ojour 

NC 

Lun 17/04/06 

3 jours 

~T 

Lun02/01C6 

Lun 02/01/06 

ojouT 

Ven 13/01/06 

Mer 1 1 J01 /06 ; 

2 jours 

"T” 

Lun 16/01 (06 

Jeu 12/01/06! 

2 jours 

Mer 18/01/06 

Lun 16/01/06 

2 jours 

4 

Jeu 19/01/06 

Mar 17/01/06 

2 jours 

NC 

Lun 27/02/06 

3 jours 

6 

Lun 09/01/06 

Jeu 12/01/06 

-3 jours 

Marl 0/01/06 i 

Ven 13/01/06 

-3 jours 

7 

Mer 11/01/06 

Lun 16/01/06 

-3 jours 

NC 

Ven 03/02/06 

-1 jour 

9 

Lun 02/01/06 

Lun 02/01/06 

Ojour 

Ven 06/01 i06 

Mer 11/01/06 

- 3 i° urs 


NB : Si Ton veut que les valeurs du champ « % de Travail acheve » soient 
visibles sur le diagramme de Gantt, il faut le specifier, par exemple a l’aide de 
l’Assistant Diagramme de Gantt du menu Format dans la rubrique « Infos sur la 
tache personnalisee ». 
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15.4.3 Saisie de I’avancement du projet Parking a la fin fevrier 

A titre d’illustration, on va maintenant montrer une saisie simplifiee, lorsque 
Ton ne veut pas suivre les jours calendaires precis pendant lesquels le travail reel 
a ete effectue. 

On choisit une option permettant de mettre a jour automatiquement le 
travail des ressources par Outils, Op tions... avec l’onglet Calcul : 



On choisit Affichage, Gantt suivi et Table : Avancement. On modifie la 
table Avancement par Table : Plus de tables... pour y rajouter les champs 
Initiales de la ressource et Travail reel par le bouton Inserer : 
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L’ application de cette table nous foumit tous les champs necessaires a la saisie 
simplifiee. On procede de la fagon suivante : 

• On commence par changer la date du jour par Projet, Informations sur le 
projet... et on met la « Date actuelle » au 1/3/06. 

• Pour plus de commodite, on restreint l’affichage aux taches inachevees par 
Projet, Filtre pour : Taches inachevees, tout en laissant les taches triees 
sur l’lnitiale de la ressource (decroissant), puis par N° (croissant). 

• Pour les taches ayant commence pendant le mois, on saisit la date de 

Debut reel. 

• Pour toutes les taches sur lesquelles la ressource a travaille pendant le mois 
de fevrier, on saisit dans la colonne Travail reel la somme du temps deja 
passe en janvier (qui est affiche) et du temps passe en fevrier. Par exemple, 
sur la tache ‘Parking PGM’, on a deja 8 jours dans Reel, il faut remplacer 
cette valeur par 26 puisque Claude a travaille 18 jours sur cette tache en 
fevrier. 

• Pour les taches terminees, on saisit 0 dans la colonne Travail restant si ce 
n’est pas deja la valeur affichee ainsi que la date de Fin reelle. 

• Pour les taches non terminees, on modifie eventuellement la valeur affi- 
chee dans Travail restant, si elle ne correspond pas au Reste a faire reel en 
fin de mois. 
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On saisit l’avancement de fevrier correspondant aux donnees suivantes : 


Nom 

Tache 

Date 

debut 

Date 

fin 

Temps 

passe 

Reste a faire 

Claude 







Parking PGM 



18 

8 

Camille 







Vehicule PGM 


2/2/06 

2 

0 


Vehicule TEST 

3/2/06 

7/2/06 

3 

0 


Autorisation ET 

8/2/06 

9/2/06 

2 

0 


Autorisation PGM 

10/2/06 


12 

13 


Ce qui nous donne : 


| 

Init.R 

Nom de la tache 

Debut reel 

Fin reelle 

T. Reel 

T Restart 



B Parking 

Lun 02/01/06 

NC 

74 jours 

56,5 jours 

D 

CL 

Parking PGM 

Jeu 1 9/01 /06 

NC 

26 jours 

8 jours 

1 

CL 

Parking TEST 

NC 

NC 

Ojour 

2 jours 

m 

CL 

Edition JE 

NC 

NC 

Ojour 

3 jours 


CL 

Edition ET 

NC 

NC 

Ojour 

1 ,5 jours 


CL 

Edition PGM 

NC 

NC 

Ojour 

1 5 jours 


CL 

Edition TEST 

NC 

NC 

Ojour 

1 ,5 jours 


CA 

VehfculePGM 

Mer 11/01/06 

Jeu 02/02/06 

1 2 jours 

Ojour 


CA 

Vehicule TEST 

Ven 03/02/06 

Mar 07/02/06 

3 jours 

Ojour 

10 

CA 

Autorisation ET 

Mer 03/02/06 

Jeu 09/02/06 

2 jours 

Ojour 

m 

CA 

Autorisation PGM 

Ven 1 0/02/06 

NC 

12 jours 

1 3 jours 

l 2 

CA 

Autorisation TEST 

NC 

NC 

Ojour 

2,5 jours 

1 

CA 

Integration 

NC 

NC 

Ojour 

1 0 jours 

i 

Debut 

NC 

NC 

Ojour 

Ojour 

imH 

Fin 

NC 

NC 

Ojour 

Ojour 


Pour etudier le recapitulatif de fevrier, on veut restreindre l’affichage aux taches 
qui ont ete actives durant le mois. 



: ill 
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Pour cela, on definit un nouveau filtre, appele RecapitulatifFevrier par 
Projet, Filtre pour : Plus de filtres... On fait une copie du filtre Recapitulatif 
que Ton modifie ainsi : 



Avec la table Avancement, le tableau obtenu est le suivant : 


Ress. 

No in cle latache 


Fin reelle 

Travail reel 

Travail reslant 


S Parking 

02 Jan 06 

NC 

74 jours 

56,5 jours 

cl] 

Parking PGM 

19 Jan 06 

NC 

26 jours 

8 jours 

ca; 

Vehicule PGM 

11 Jan 06 

02 Fev 06 

1 2 jours 

0 jour 

CAj 

Vehicule TEST 

03 Fev 06 

07 Fev 06 

3 jours 

Ojour 

CA 

Autorisation ET 

08 Fev 06 

09 Fev 06 

2 jours 

Ojour 

CA; 

Autorisation PGM 

lOFev 06 

NC! 

12 jours 

13 jours 


On obtient le recapitulatif suivant avec la table Recapitulatif : 


In#, Ress. Nom de la tithe 

%Trav.Acheve 

TravReei 

1 Trav .Restart j 

Trav.Planifie 

Var .TraVall 

E Parking 

57% 

74 jours 

56,5 jours 

130 jours 

0,5 jour 

* 

Parking PGM 

76% 

26 jours 

8 jours 

30 jours 

4 jours 

CA 

VeNcule PGM 

100% 

12 jours 

Ojour 

15 jours 

-3 jours 

L « 

Vehicule TEST 

100% 

3 Jours 

Ojour 

1.5 jours 

1,5 jours 


Autorisation ET 

100% 

2 jours 

Ojour 

2 jours 

Ojour 

a - 

Autorisation PGM 

48% 

12 jours 

13 jours 

25 jours 

Ojour 


On peut relever que le mode de calcul du champ % Travail acheve differe de 
la definition de l’avancement que nous avons donnee et illustree, comme une 
difference entre deux Reste a faire. 
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En effet, pour MS Project, la definition est : 

%Travail acheve = [Travail reel/(Travail reel + Travail restant)] x 100. 

C’est done la part realisee de la nouvelle prevision. Si Ton prend ParkingPGM, 
on a bien : 

76 % = (26/(26 + 8)) x 100. 


15 A A Bilan individuel du projet Parking a la fin fevrier 

On va utiliser une table standard de suivi des couts, telle que foumie par MS 
Project. On a besoin pour cela d’indiquer la date a laquelle on veut faire le bilan, 
e’est-a-dire la fin fevrier, et ceci correspond a la date d’etat que Ton trouve dans 

Projet, Informations sur le projet... 



On peut alors utiliser Affichage, Utilisation des ressources avec la Table : 
Audit des couts, dont nous allons expliquer la signification des champs qui y 
figurent. Ils sont tous en devises (Euros), mais on peut etablir des correspondances 
avec les indicateurs proposes au chapitre 12. 



Si l’on traduit ces montants en devises en jours de travail, en les divisant par 
le cout joumalier de chaque ressource (350 euros pour Claude et 560 euros pour 
Camille), cela donne les valeurs suivantes : 



CBTP 

CBTE 

CRTE 

VS 

VC 

FAC 

BAC 

VAC 

CL 

42 

33,94 

38 

-8,05 

-4,05 

69 

64 

-5 

CA 

42 

40,5 

36 

-1,5 

4,5 

61,5 

66 

4,5 
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Nous allons rappeler la signification et le mode de calcul de ces indicateurs 
lies a la methode de la valeur acquise, exposee au paragraphe 7.3., mais avec 
l’ancienne terminologie : 

• Le CBTP, Cout Budge te du Travail Prevu, correspond a la Valeur plani- 
fiee (VP) : c’est le cout qui aurait du etre engage selon la planification 
initiale. Ramene en jours, c’est le temps qui aurait du etre consacre au 
projet. II peut aussi etre considere comme l’avancement planifie. Pour les 
deux intervenants, la valeur est de 42 jours, c’est-a-dire un plein temps en 
janvier et fevrier 2006. 

• Le CBTE, Cout Budgete du Travail Effectue, correspond a la Valeur 
acquise (VA) : cet indicateur represente un avancement reel. II est calcule 
en multipliant, pour chaque tache affectee, le pourcentage de travail 
acheve par la charge initiale valorisee au cout des ressources. C’est done : 
[Travail reel/ (Travail reel + Travail restant)] * Charge initiale. 

• Le CRTE, Cout Reel du Travail Effectue, correspond au Cout reel (CR) : 
c’est le temps reellement passe sur le projet. 

Si le CRTE est superieur au CBTE, cela signifie que la performance n’est 
pas bonne : les intervenants consomment trap de temps par rapport a leur 
avancement. 

Si le CRTE est inferieur au CBTP, cela signifie que ce que nous avions 
appele le « coefficient d’utilisation » au chapitre 12 est inferieur a 1 : les 
intervenants consacrent moins de temps que prevu au projet ! 

• VS, Value Schedule, appele maintenant Ecart de delai, mesure la difference 
entre l’avancement reel et l’avancement planifie. II est calcule par : 

CBTE - CBTP. 

Si le VS est negatif, c’est que la production n’est pas aussi avancee que prevu. 

• VC, Value Cost, appele maintenant Ecart de cout, mesure la difference 
entre l’avancement reel et le temps passe. II est calcule par : 

CBTE -CRTE. 

Si le VC est negatif, c’est que la production consomme plus de temps que 
ce que l’on avait planifie. 

• FAC, Forecast At Completion, appele maintenant Prevision a l’acheve- 
ment : c’est l’estimation de cout la plus vraisemblable compte tenu des 
informations dont on dispose a la date t. Cet indicateur correspond a la 
charge previsible a ce jour, e’est-a-dire la somme du Travail reel (Temps 
passe) et du Travail restant (Reste a faire). II prend en compte toutes les 
taches affectees, y compris celles qui ne sont pas commencees. 

Pour Claude, les 69 jours correspondent aux 38 jours de travail reel, plus 
8 jours de travail restant sur ParkingPGM, plus les 23 jours des taches 
affectees et non commencees (ParkingTEST et tout le lot Edition). 
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Pour Camille, les 61,5 jours correspondent aux 36 jours deja consommes, 
auxquels s’ajoute le reste de AutorisationPGM (13 jours), Autorisation- 
TEST (2,5 jours) et Integration (10 jours). 

BAC, Budgeted At Completion, maintenant appele Budget a l’achevement : 
c’est le cout total planifie. Cet indicateur correspond a la totalite de la 
charge affectee. 

Les chiffres correspondent bien aux 64 jours de charge initialement planifies 
pour Claude, et 66 pour Camille. 

VAC, Variance At Completion, maintenant appele Ecart a l’achevement, 
est la difference entre le cout total planifie et le cout previsible, c’est- 
a-dire BAC - FAC. Cet indicateur correspond a revolution positive ou 
negative de la charge : ramene en jours, c’est la difference entre le temps 
passe et l’avancement. On peut done le rapprocher de ce que nous avons 
appele la « vitesse » au paragraphe 11.5. 

Pour Claude, on trouve -5 jours qui correspondent bien a : 

38 jours (temps total passe) - 14 jours (avancement de janvier) - 19 jours 
(avancement de fevrier). 

Pour Camille, on a 4,5 jours qui correspondent bien a : 36 jours (temps 
total passe) - 23 jours (avancement de janvier) - 17,5 jours (avancement 
de fevrier). 


15.4,5 Gestion des aleas du projet Parking 

Nous allons maintenant illustrer le traitement d’aleas obligeant a modifier la 
planification : le 21 mars au soir, Claude a un accident l’immobilisant pendant 
trois jours. 

On positionne la date actuelle au 21/3/06 (Projet, Informations sur le 
projet...)- Les elements au 21 au soir sont les suivants : 


Claude 



1/3 

2/3 

3/3 

Reste a faire 

Parking PGM 



1 

1 

1 

6 


6/3 

7/3 

8/3 

9/3 

10/3 

Reste a faire 

Parking PGM 

1 

1 

1 

1 

1 

3 


13/3 

14/3 

15/3 

16/3 

17/3 

Reste a faire 

Parking PGM 

1 

1 

1 

1 


0 


20/3 

21/3 

22/3 

23/3 

24/3 

Reste a faire 

Parking TEST 


1 




2 


a 
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Camille 

Autorisation PGM 


Autorisation PGM 


Autorisation PGM 


Autorisation PGM 


6/3 


13/3 


20/3 


7/3 


14/3 


21/3 


1/3 

1 

8/3 


15/3 


22/3 


2/3 

1 

9/3 


16/3 


23/3 


3/3 


10/3 


17/3 


24/3 


Reste a faire 


10 


Reste a faire 


7 


Reste a faire 


2 


Reste a faire 


On saisit l’avancement par la methode 1 (en commengant par enlever 
l’option de calcul : Outils, Op tions : « La mise a jour de l’etat des taches entraine 
la mise a jour de l’etat des ressources ») : 

Pour analyser la situation apres avoir fait la saisie , on regarde le Gantt par 
Affichage, Gantt suivi et Projet, Fibre pour : Taches inachevees. 

On obtient : 




15.4. Pilotage du projet Parking 


a 


On voit que la fin du projet est repoussee du 17 avril au 5 mai, a cause du 
retard de Claude. 

Pour resorber ce retard, on modifie done les affectations (et les predecesseurs) 
par Affichage, Diagramme de Gantt avec Table : Entree : 

• La tache ‘Edition JE’ est confiee a Boss, le chef de projet, qui commencera 
des le lendemain (22/3/06). La liaison doit etre supprimee. 

• La tache ‘Edition ET’ est confiee a Camille : elle la fera juste apres ‘Auto- 
risation PGM’et avant ‘Autorisation TEST’. 

• La tache ‘Edition PGM’ aura comme predecesseur la tache ‘Parking 
TEST’. 

• La tache ‘Integration’ commencera avant la fin du lot Edition. 

On modifie les calendriers personnels par Outils, Modifier le temps de 
travail... : 

• Camille, qui devait partir le 22 mars au soir, viendra travailler les 22 et 23 
toute la joumee, ainsi que le 24 au matin. En revanche, elle ne reviendra 
de conge que le 5 avril apres-midi, au lieu du 4 au matin. 

• Claude viendra travailler les trois premiers samedis d’ avril : l er , 8 et 15. 
II sera absent : les 22, 23 et 24 mars. 


Apres avoir modifie 1’ affectation des ressources et le ou les predecesseurs de 
chaque tache, on obtient : 


78 jours Lun 02/01/06 


Ven 21/04/D6 


jn 02/01/06 


Autorisation PGM 
Autorisation TEST 


2, 5 jours 


10 jours | 


Ven 1 0/02/06 
Mer 05/04/06 
Mer 22/03/06 
Jeu 23/03/06 
Mer 29/03/06 
Sam 15/04/06 
Lun 10/04/06 
0 jour | Ven 21/04/06 


Mar 28/03/06 4 
Mer 22/03/06 1 0 
Ven 07/04/06 14 


15.4.6 Tableau d’avancement du projet Parking a la fin mars 

Fin mars, nous allons presenter un tableau d’avancement pour le maitre d’ouvrage, 
qui sera une synthese par lots. 
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0 


L’avancement reel a ete le suivant : 


Claude 

20/3 

21/3 

22/3 

23/3 

24/3 

Reste a faire 

Parking TEST 


1 




2 


27/3 

28/3 

29/3 

30/3 

31/3 

Reste a faire 

Parking TEST 

1 

1 




0 

Edition PGM 



1 

1 

1 

12 


Camille 

20/3 

21/3 

22/3 

23/3 

24/3 

Reste a faire 

Autorisation PGM 


1 

1 



0 

Edition ET 




1 

1 

0 


27/3 

28/3 

29/3 

30/3 

31/3 

Reste a faire 

Conge 








Boss 

20/3 

21/3 

22/3 

23/3 

24/3 

Reste a faire 

Edition JE 




1 

1 

2 


27/3 

28/3 

29/3 

30/3 

31/3 

Reste a faire 

Edition JE 

1 

1 




0 


On effectue la mise a jour par la methode 1. 

15.4.7 Presentation par lots 

Ensuite, on prepare une presentation de l’avancement par lot. Pour cela, on va 
introduire quatre taches recapitulatives : Lot Parking, Lot Edition, Lot Vehicule, 
Lot Autorisation et Lot Integration. 

On selectionne Affichage, Diagramme de Gantt avec Table : Entree. 

On se place sur la tache ‘Parking JE’ et on cree une nouvelle tache que l’on 
appelle Lot Parking par Insertion, Inserer une tache. On insere ensuite les cinq 
autres taches recapitulatives au-dessus de la premiere tache du lot. 

Ensuite, on selectionne les quatre taches du lot Parking et on descend leur 
niveau hierarchique en cliquant sur l’icone Abaisser en haut a gauche de l’ecran : 


15.4. Pilotage du projet Parking 


a 



Les quatre taches ont ete decalees par rapport a la tache recapitulative Lot 
Parking. 

On fait de meme pour les quatre autres lots : Edition, Vehicule, Autorisation, 
Integration. On obtient la presentation suivante par Affichage, Diagramme de 
Gantt avec Table : Travail : 
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Le champ Planifie des taches recapitulatives n’a pas ete mis a jour et reste a 0 
pour les cinq lots. On va introduire ces taches dans la planification. 

On selectionne les cinq taches recapitulatives (a l’aide de la touche Ctrl). 
On utilise Outils, Suivi, Enregistrer la planification initiale... et on choisit : 



On observe alors que le planifie des taches recapitulatives a ete mis a jour et 
correspond a la somme (Reel + Restant). Si on filtre le projet par Projet, Filtre 
pour : Taches recapitulatives, on obtient le tableau suivant : 



Non> de la tache 

Travail 1 


Variation ! 

Reel Restant 

0 

PI Parking 

138 jours 

130 Jours 

8 jours 

112 jours 

26 jours 

2 

0 Lot Parking 

S3 jours 

43 jours 

10 jours 

S3 jours 

® jour 


B Lot Vehicule 

IT jours | 

18,5 jours 

■1,5 jours 

17 jours 

Ojour 

11 • 

E Lot Autorisation 

35,5 jours 

37,5 jours 

-2 jours 

33 jours 

2,5 jours 

16 

El Lot Edition 

22,5 jours 

21 jours 

1,5 jours 

9 jours 

13,5 jours 

21 

E Lot Integration 

10 jours 

10 jours 

0 jour 

Ojour 

1 0 jours 


Le lot Parking a une valeur incorrecte, car juste avant la planification initiale 
on a ajoute 2 jours de charge supplementaire a Claude pour la tache ‘Parking JE’: 
on modifie le planifie en reprenant les valeurs initiales et en conservant la valeur 
de 6 jours pour la tache ‘Parking JE’, c’est-a-dire : 

| Lot Parking | 41 


15.5. Bilan du projet Parkins 


a 


On peut maintenant filtrer le projet par Projet, Filtre pour : Taches recapi- 
tulatives et on obtient le tableau d’avancement suivant par Affichage, Gantt 
suivi avec Table : Travail : 



Norn de la tache 

Travail 

Planifie 

Variation 

Reel | 

Restart 

0 

3 Parking 

138 jours 

130 jours 

8 jours 

112 jours 

26 jours 


El Lot Parking 

53 jours 

41 jours 

12 jours 

53 jours 

0 jour 

7 

ID Lot Vehicule 

17 jours 

IS, 5 jours 

-1,5 jours 

17 jours 

Ojour 

CT 

El Lot Autorisation 

36,5 jours 

37,5 jours 

-2 jours 

33 jours 

2,6 jours 

16 

H Lot Edition 

22,5 jours 

21 jours 

1,5 jours 

9 jours 

13,5 jours 


E Lot Integration 

10 jours 

10 jours 

0 jour 

0 jour 

10 jours 


Ce tableau pourra etre fourni periodiquement au maitre d’ouvrage. 


15.5 BILAN DU PROJET PARKING 

15.5.1 Tableau d’avancement final du projet Parking 

On effectue les demieres mises a jour des travaux d’avril. Compte tenu de 
l’echeance, plusieurs decisions ont ete prises : 

Camille est rentree des le 5 avril au matin et elle est venue travailler trois 
samedis : les 8, 15 et 22 avril. On met done a jour son calendrier. 

La tache ‘Edition PGM’ a ete repartie entre trois personnes : Claude, Camille 
et Boss. On precede de la fagon suivante : 

Sur la vue Affichage, Diagramme de Gantt avec Table : Entree, on rajoute 
la tache ‘Edition PGM’ comme predecesseur de la tache Integration. On modifie 
les ressources affectees a la tache ‘EditionPGM’ par : 
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El 


On peut observer que la duree a ete reduite automatiquement par MS Project : 



° 

N ° mdeia,sche 


“i i - 

Predecesseurs 

Moms ressources 

0 


B Parking 

76,75 jours 

Lun 02/01/06 Jeu 20704/06 



1 


Debut 

Qjcur 

Lun 02/01/06 Lun 02/01/06 



11 


El Lot Autorisstion 

67,5 jours 

Lun 02/0*1/06 Ven 07*406 



IS 


Autorisstion TEST 

2~5 jours 

Mer OSMM6 Ven 07/04/06 i 

18 

Camille 

16 


B Lot Edition 

13,25 jours 

Jeu 23*3*6 Mar 11*4*6 



19 


Edition PGM 

9,75 jours 

Mer 29/03/06 Sam 08/04/06 

6 

Claude, Camille, Boss 

20' 


Edition TEST 

1,5 jours 

Sam 08/04/06 Mar 11/04/06 

19 

Claude 

21 


B Lot Integration 

8,75 jours 

Sam 08*4*6 Jeu 20*4*6 



~W 


Integration 

10 jours 

Sam 08/04*6 Jeu 20*4/06 : 

15;19 

Camille 

23 


Fin 

0 jour 

Jeu 2Q*4*6 Jeu 20*4*6 

22 



n 



1 


Nous allons maintenant Mettre a jour le projet. L’avancement reel de chaque 
ressource se presente comme suit : 


Claude 






1/4 

Reste a faire 

Edition PGM 






1 

6 


3/4 

4/4 

5/4 

6/4 

7/4 

8/4 

Reste a faire 

Edition PGM 

1 

1 

1 

1 

1 

1 

3 


10/4 

11/4 

12/4 

13/4 

14/4 

15/4 

Reste a faire 

Edition PGM 

1 

1 

1 

1 

1 

1 

0 


17/4 

18/4 

19/4 

20/4 

21/4 

22/4 

Reste a faire 

Edition TEST 

1 

1 





0 


Camille 






1/4 

Reste a faire 

Conge 






1 



3/4 

4/4 

5/4 

6/4 

7/4 

8/4 

Reste a faire 

Autorisation TEST 



1 

1 

1 


0 

Edition PGM 






1 

2,5 


10/4 

11/4 

12/4 

13/4 

14/4 

15/4 

Reste a faire 

Edition PGM 

1 

1 

1 

0,5 



0 

Integration 




0,5 

1 

1 

7,5 


17/4 

18/4 

19/4 

20/4 

21/4 

22/4 

Reste a faire 

Integration 

1 

1 

1 

1 

1 

1 

0 


EfcTtefefcbl] 
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Boss 






1/4 

Reste a faire 










3/4 

4/4 

5/4 

6/4 

7/4 

8/4 

Reste a faire 

Edition PGM 

1 

1 

1 




0 


Apres mise a jour, le recapitulatif, filtre sur les taches recapitulatives, 
presente ainsi : 



0 Lot Parking 
0 Lot Vehicule 


0 Lot Autorisation 
0 Lot Edition 
0 Lot Integration 


yia 

mm 


■mi 

Httfil 

100% 

146 jours 

0 jour 

130 jours 

16 jours 

100% 

S3 jours 

0 jour 

41 jours 

12 jours 

100% 

17 jours 

0 jour 

18,5 jours 

-1,5 jours 

100% 

36 jours 

0 jour 

37,5 jours 

1,5 jours 

100% 

31,5 jours 

0 jour 

21 jours 

10,5 jours 

100% 

0,5 jours 

# jour 

10 jours 

-1,5 jours 







On peut y observer que le Travail planifie de la tache recapitulative du projet 
Parking est de 130 jours, et non de 128. C’est en effet la valeur de la planification 
initiale, avec une charge affectee differente de la charge estimee. On peut, si on 
le souhaite, ramener cette valeur a 128 jours. 

15.5.2 Tableau de bilan du projet Parking 

Pour construire un bilan des ecarts de charge, on va supprimer les taches recapi- 
tulatives et operer un regroupement par nature de tache. 

Pour cela, on selectionne la vue Affichage, Diagramme de Gantt avec 
Table : Entree. Ensuite, on precede de la fagon suivante : 

On remonte toutes les taches de second niveau : on obtient une liste avec 
toutes les taches au meme niveau. 

On peut alors supprimer les quatre taches : Lot Parking, Lot Autorisation, 
Lot Vehicule et Lot Edition, sans supprimer les taches figurant dans les lots. 

On cree de nouvelles taches recapitulatives, correspondant aux types de tache 
utilises pour l’estimation et pour lesquels on veut suivre les ecarts entre le planifie 
et le reel. 
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On deplace les taches par Couper-Coller de fagon a ce que les nouvelles taches 
recapitulatives soient situees juste au-dessus des taches qu’elles recapitulent. 

La typologie est la suivante : 


Type de tache 

Taches 

Jeu essai 

Parking JE 
Autorisation JE 
Edition JE 

Etude technique temps reel 

Parking ET 
Vehicule ET 
Autorisation ET 

Etude technique batch 

Edition ET 

Programme moyen temps reel 

Parking PGM 
Vehicule PGM 

Programme difficile temps reel 

Autorisation PGM 

Programme batch facile 

Edition PGM 

Test 

Parking TEST 
Vehicule TEST 
Autorisation TEST 
Edition TEST 

Integration 

Integration 


15.5. Bilan du projet Parkins 


a 


On obtient une nouvelle liste hierarchisee qui se presente ainsi : 


N’ 

Init-Ress. 

Nomctetetaghe: 

%TrsVjAcheve 

Trav.Reel 

1 


B Parking 

100% 

146 jours 

1 


Debut 

0% 

Ojour 

2 


B JEU ESSAI 

100% 

IS jours 

3 

CL 

Parking JE 

100% 

9 jours 

4 

CA 

Autorisstion JE 

100% 

5 jours 

5 

00 

EdRionJE 

100% 

4 jours 

6 


B ETUDE TECHNIQUE 

100% 

1 Jours 

7 

CL 

Parking ET 

100% 

3 jours 

8 

CA 

Vehicule ET 

100% 

2 jours 

9 

CA 

Autor isation ET 

100% 

2 jours 

10 


B ETUDE TECHNIQUE 

100% 

2 jours 

or 

CA 

Edition ET 

100% 

2 jours 

12 


E PROGRAMME fscil 

100% 

23,5 jours 

13 

CL;CA;0O : 

Edition POM 

100% 

23 ,5 jours 

14 


B PROGRAMME mov 

100% 

50 jours 

15 

CL 

Parking PGM 

100% 

38 jours 

16 

CA 

Vehicule PGM 

100% 

12 jours 

17 


B PROGRAMME dlffi. 

100% 

26 jours 

« 

CA 

Autorisstion PGI 

100% 

26 jours 

19 


B TEST 

100% 

11 jours 

20 

CL 

Parking TEST 

100% 

3 jours 

21 

CA' 

Vehicule TEST 

100% 

3 jours 

IT 

CA 

Autorisstion TEE! 

100% 

3 jours 

23 

~CL| 

Edition TEST 

100% 

2 jours 

24 


B INTEGRATION 

100% 

8,5 jours 

25 

CA 

Integration 

ioo% 

8,5 jours 

26 


_ Fin 

0% 
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Pour visualiser les ecarts, on utilise Affichage, Gantt suivi ; on cree une table 
Bilan contenant les cinq champs N°, Nom, Travail planifie, Travail reel et 
Variation de travail. On ajuste les valeurs du travail planifie des taches recapitu- 
latives. En filtrant sur les taches recapitulatives, on obtient le tableau suivant : 


"■ 

■ 

NOM 




1M 

B 

Parking 

130 jours 

146 jours 

16 jours 

p m 


Debut 

0 jour 

Ojour 

Ojour 

i 

a 

JEU ESSAI 

19 jours 

18 jours 

-1 jour 

i 

hi 

ETUDE TECHNIQUE temps reel 

/jours 

/jours 

Ojour 

1U 


ETUDE TECHNIQUE batch 

1,5 jours 

2 jours 

0,6 jour 

12 

a 

PROGRAMME facile batch 

IS jours 

23,5 jours 

0,5 jours 


a 

PROGRAMME moyen temps reel 

45 jours 

50 jours 

5 jours 


a 

PROGRAMME difficile temps reel 

25 jours 

25 jours 

1 jour 

19 

a 

TEST 

7,5 jours 

11 jours 

3,5 jours 

24 

a 

INIEGKA1ION 

10 tours 

0,5 lours 

■1,5 lours 

2S 


Finj 

Ojour 

Ojour 

Ojour 


Ainsi s’acheve l’illustration de l’outil MS Project, avec lequel nous avons 
propose des choix de planification et de suivi coherents avec les principes 
presentes au chapitre 12. Le progiciel offre d’autres possibilites, pour lesquelles 
nous renvoyons a sa documentation propre. Nous avons essaye de concilier 
d’une part la simplicity — des manipulations et de la lecture des differents 
tableaux de bord — et d’autre part les informations de suivi indispensables au 
chef de projet. Le cas Parking a permis de simuler un avancement et des actions 
de pilotage realistes, de la planification jusqu’au bilan. 


Troisieme partie 


Lcs referentiels 
et la certification en 
management de projet 


Cette troisieme partie s’adresse au lecteur qui souhaite approfondir sa 
connaissance des referentiels et/ou preparer une certification en management de 
projet, et tout particulierement cede du PMI. 

Le chapitre 16 presente les principals associations professionnelles dans le 
domaine de la gestion de projet, ainsi que la norme ISO 10006 qui traite de la 
qualite specifique au management de projet. On y a ajoute le cadre propose par 
Euromethode pour les appels d’offres publics au niveau europeen. 

Le chapitre 17 constitue une bonne introduction a la certification PMI : il 
comporte de nombreux renvois aux differentes techniques exposees dans la 
premiere partie de cet ouvrage. 



16 


Associations, normes 
et cadres de reference 


16.1 LES ASSOCIATIONS PROFESSIONNELLES 


L’AFITEP ( Association Francophone de Management de Projet) 1 anciennement 
Association Franchise des Ingenieurs et Technicians en Evaluation et Planification 
de Projet, fondee en 1982, organise des rencontres et publie une revue profes- 
sionnelle, La Cible. Elle est associee aux principales federations intemationales 
de management de projet 

Le PMI ( Project Management Institute) 2 , association americaine de profession- 
nels, fondee en 1969, est aujourd’hui federee en chapitres nationaux et regroupe 
pres de 100 000 membres dans le monde. Son referential a ete reconnu comme 
une norme aux Etats-Unis par l’ANSI, institut de normalisation americain. 

L’lPMA ( International Projet Management Association) 3 , association interna- 
tionale fondee en 1967, federe pres de 40 associations nationales. Elle organise 
des congres et des echanges, et regroupe environ 25 000 membres. 

L’ICEC ( International Cost Engineering Council ) 4 est une federation dissocia- 
tions orientees vers la maitrise des couts, qui comprend environ 50 000 adhe- 
rents dans 38 pays. 

1. http://www.afitep.fr. 

2. http://www.pmi.org. 

3. Association intemationale de gestion de projet, http :// www.ipma.ch. 

4. Conseil international de l’ingenierie des couts, http://www.icoste.org. 
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L’objectif de certification a conduit a une definition normalisee du vocabulaire 
et des competences requises pour conduire des projets. De plus, compte tenu de 
l’importance prise par les organisations du travail en mode projet, les organismes de 
normalisation ont egalement travaille sur la definition des termes et des activites. 

Pendant longtemps, la gestion de projet n’a pas ete consideree comme une 
discipline academique, au meme titre que les autres specialites de la gestion. 
Depuis quelques annees, la gestion de projet n’est plus etrangere a la recherche 
academique, ce que l’on peut observer a travers deux phenomenes : d’une part 
des revues specialises, comme 1’ International Journal of Project Management ou 
Project Management Journal font une large place a la recherche ; d’autre part, les 
revues scientifiques, notamment dans les domaines systeme d’information et 
informatique, s’interessent de plus en plus a la gestion des projets. Une selection 
d’articles est donnee dans la bibliographic. 


16.2 LA NORME IS010006 

La norme ISO 1 0006 1 traite de la qualite dans le management de projet et decrit, 
de fagon structuree, les activites a accomplir pour gerer un projet avec des exi- 
gences de qualite. La version 2003 2 est alignee sur la norme IS09000 version 2000, 
qui traite du management de la qualite et defend une vision par processus de la 
gestion d’une organisation. Le processus est defini comme un « ensemble d’ activites 
correlees ou inter actives qui transforme des elements d’ entree en elements de sortie ». 

Pour la norme ISO 10006 : 2003, les processus sont regroupes en quatre 
families. 

• La premiere ne comprend qu’un seul processus, appele processus strategique, 
qui est de la responsabilite de la direction de l’entreprise. 

• La deuxieme famille comprend des processus qui touchent a la gestion des 
ressources, en particulier le personnel. 

• La troisieme famille de processus touche a la realisation du produit, c’est-a- 
dire la production du bien ou service vise par l’objectif. Elle comprend la 
coordination des activites, la maitrise des taches de production, celle des 
delais et des couts, la gestion de la communication, la maitrise des risques 
et celles des achats pour le projet. 

• La quatrieme famille de processus touche a l’ amelioration, c’est-a-dire le 
management des connaissances issues des projets acheves. 


1 . Elle s’intitule « Systemes de management de la qualite. Lignes directrices pour le management 
de la qualite dans les projets ». 

2. Cette version est actuellement en cours de revision, avec notamment la participation du PMI. 


16.2. La norme IS010006 


a 


Nous allons detailler le contenu de chaque famille. 

1. Famille du processus strategique. 

Le but de ce processus est d’inciter la direction de l’entreprise a mettre en 
place un dispositif qualite adapte au projet. Apres avoir nomme un chef de 
projet, la norme recommande que la direction soit attentive a plusieurs aspects 
dans le deroulement du projet, notamment : 

• la prise en compte des besoins et des attentes du client et des autres parties 
prenantes du projet (personnel, foumisseurs, banquiers, syndicats, parte- 
naires, societe...) ; 

• Pimplication des acteurs a tous les niveaux ; 

• l’etablissement de relations mutuellement benefiques avec les fournisseurs. 

De plus, chaque projet doit etre l’occasion d’ameliorations dans le management 
de projet. 

2. Famille des processus relatifs aux ressources et au personnel. 

Les processus relatifs aux ressources ont pour but d’une part leur planification, 
c’est-a-dire identifier, estimer et allouer celles qui seront necessaires ; d’autre 
part leur controle, c’est-a-dire s’assurer qu’elles sont suffisantes pour atteindre les 
objectifs du projet. 

Les ressources doivent s’entendre au sens large : equipements, installations, 
finance, informations, materiels, logiciels, personnel, services et locaux... 

Les processus relatifs au personnel ont pour but de creer un environnement dans 
lequel le personnel peut apporter une contribution efficace et efficiente au projet. 
Cela implique de definir la structure du projet (les roles et les responsabilites), de 
selectionner et affecter le personnel, et de former l’equipe pour obtenir les 
competences individuelles et collectives necessaires. 

3. Famille des processus relatifs au produit. 

Les processus relatifs a la coordination ont pour but de gerer les interdependances 
entre les travaux et les actions. Pour cela, il faut : 

• lancer le projet et elaborer le plan de management de projet, document 
qui decrit comment on va atteindre les objectifs du projet ; 

• gerer les interactions entre les travaux des differents acteurs ; 

• gerer les modifications, notamment cedes qui touchent le perimetre ou les 
objectifs du projet ; 

• clore le projet et faire le bilan. 


a 
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Les processus relatifs au contenu du projet ont pour objectif de s’assurer de 
l’achevement et de la qualite du produit. Pour cela, il faut : 

• traduire les besoins et attentes du client et des autres parties prenantes en 
activites necessaires pour accomplir les objectifs du projet, et organiser ces 
activites (definition des activites) 

• s’assurer que le personnel travaille dans le perimetre du projet durant 
I’execution des activites (controle des activites) 

• s’assurer que les resultats satisfont aux exigences (controle des activites). 

Les processus relatifs aux delais ont pour but de maitriser les delais. Pour cela, il 
faut : 


• identifier les liaisons entre les taches ; 

• estimer les durees des taches ; 

• elaborer le planning ; 

• comparer le reel et le planifie, et prendre des mesures correc trices 
(controle des delais). 

Les processus relatifs aux couts ont pour but de maitriser les couts du projet. 
Pour cela, il faut : 

• estimer les couts ; 

• faire un budget, qui montre la repartition des depenses dans le temps ; 

• suivre les depenses reelles, estimer les tendances, identifier l’origine des 
ecarts par rapport au budget et prendre des mesures (controle des couts). 

Les processus relatifs a la communication ont pour but de faciliter les echanges 
internes et externes d’ information, necessaires au projet. Pour cela, il faut : 

• planifier les actions de communication (quoi, qui, comment) ; 

• gerer l’information (utiliser des procedures pour controler la preparation 
de l’information, la collecte, l’identification, la classification, la mise a 
jour, la distribution, le stockage, l’archivage, la protection, l’acces, la duree 
de conservation, la suppression) ; 

• controler la communication, pour eviter les malentendus et les conflits. 

Les processus relatifs aux risques ont pour but de minimiser l’impact d’evene- 
ments potentiellement negatifs pour le projet et de tirer parti d’opportunites 
d’amelioration. 


16.2. La norme IS010006 


a 


Pour cela, il faut : 

• identifier les risques (cout, delai, produit, securite, sante, environne- 
ment...) ; 

• evaluer les risques (en utilisant F experience et les donnees memorisees de 
projets anterieurs) ; 

• traiter les risques, c’est-a-dire elaborer des solutions pour eliminer, reduire, 
transferer, partager ou supporter les risques ; 

• controler les risques, c’est-a-dire suivre et gerer les aleas tout le long du 
projet. 

Les processus relatifs aux achats ont pour but d’obtenir des produits/services 
pour le projet. Pour cela, il faut : 

• planifier les achats, en elaborant un plan d’achat ou de sous-traitance ; 

• documenter les exigences d’achat ; 

• evaluer les foumisseurs ; 

• contracter, c’est-a-dire evaluer les offfes et etablir le contrat ; 

• controler le contrat, c’est-a-dire s’assurer que les conditions du contrat 
sont satisfaites. 

4. Famille des processus relatifs a 1’ amelioration. 

Les processus relatifs a l’ amelioration ont pour but tirer les legons du projet. 
Pour cela, il faut : 

• utiliser les resultats des mesures et de l’analyse des donnees du projet 
(actions correctives, actions preventives) et Stocker les enseignements 
(prevention de la perte d’experience). 

Les processus relatifs a la mesure et l’ analyse ont pour but de produire une trace 
et une evaluation de chaque projet. Pour cela, il faut : 

• Mesurer, collecter et valider les donnees pour une amelioration efficace et 
efficiente de la performance (audit, evaluation des activites individuelles, 
evaluation des processus, mesure de l’atteinte des objectifs du projet...) 

Les processus relatifs a l’ amelioration continue ont pour but d’ameliorer en 
permanence la qualite globale des projets de l’entreprise. Pour cela, il est recoin- 
mande de mettre en place un cycle d’amelioration continue base sur la roue de 
Deming : Plan-Do-Check-Act (PDCA), planifier-faire-verifier-agir. 
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163.1 Presentation d' Euromethode 

Euromethode est un projet europeen qui a ete finance par le Groupe des 
Marches Publics de la Commission Europeenne 1 afin de definir un cadre 
contractuel pour les projets systeme d’information. II prend en compte tout 
contexte d’adaptation d’un systeme d’information, c’est-a-dire « toute forme de 
modification, amelioration, automatisation, etc. du systeme d’information, (ce 
qui inclut...) developpement, maintenance, conception, retroconception, 
installation de systeme, etc. ». La definition donnee d’un projet est plus restric- 
tive que les definitions normalisees et correspond a l’organisation humaine 
temporaire permettant de le mener a bien : « une adaptation est realisee par une 
equipe qu’on appelle le projet ». 

Euromethode decrit les obligations contractuelles respectives du client et du 
fournisseur sous 1’ angle des elements a livrer et foumit ainsi un cadre de refe- 
rence des differentes categories de foumitures susceptibles d’etre produites, par le 
fournisseur et/ou par le client, au cours d’un projet (figure 16.1). 



Figure 16.1 — Fournitures d'un projet. 


1. PPG : Public Procurement Group, qui fait partie de la DGXIII de la Commission Europeenne. 
En France sa diffusion s’est effectuee en 1995 sous le controle de la Commission Centrale des 
Marches. 
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Le plan des livraisons est elabore au moment de la passation du marche ou au 
debut du projet. II peut etre affine par la suite. II decrit les engagements recipro- 
ques du client et du foumisseur en termes d’informations a fournir ou de produits 
a livrer. 

Les fournitures relatives au domaine cible sont celles pour lesquelles le client 
paie reellement et pour lesquelles il fait appel a un foumisseur. Elies correspondent : 

• soit a tout ou partie du systeme d’information operationnel, c’est-a-dire 
l’application ou une partie de l’applicatif ; 

• soit a des descriptions du systeme d’information considere : description de 
Pexistant, description du systeme cible, documentation, plan de formation. . . 

Les fournitures relatives au domaine du projet permettent au client d’ avoir une 
visibility sur l’avancement et la qualite des travaux effectues par le foumisseur. 

Nous allons preciser le contenu de ces trois types de foumiture. 

16.3.2 Le plan des livraisons 

Le plan des livraisons contient tout d’abord la strategie d’ adaptation qui corres- 
pond en partie au choix d’un modele de cycle de vie et au choix d’un modele de 
mise en oeuvre. Euromethode propose differentes options (figure 16.2). 


Strategie d’adaptation 

Choix 

Demarche de description 
du systeme 

Analytique 

(modelisation et redaction de specifications) 
Experimental (approche par prototypage) 
Type de cooperation : projet conduit par 
des experts 

Type de cooperation : participative 

Demarche de construction 
du systeme 

En une seule fois 

Incrementale (le systeme est construit progressi- 
vement par modules) 

Evolutionnaire (le systeme est construit par ver- 
sions successives) 

Demarche de mise en service 
du systeme 

En une seule fois 

Incrementale (le systeme est mis en oeuvre 
progressivement par modules) 
Evolutionnaire (les differentes versions 
du systeme sont installees successivement) 


Figure 16.2 — Options de la strategie d’adaptation selon Euromethode. 
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La sequence et la description des points de decision correspondent aux differents 
jalons que Ton trouve dans un plan de developpement. Chaque jalon comprend 
la remise d’une fourniture au client (note, rapport, dossier, programmes...) et 
l’attente d’une prise de decision par le client (choix entre plusieurs propositions, 
validation, decision sur la suite du projet...). 

La description de la situation du probleme est foumie par le client. Elle 
comprend la description de Vetat initial et celle de l’etat final. 

L’etat initial doit permettre au foumisseur de situer le projet dans son 
contexte et de savoir ce qui s’est passe anterieurement. II doit en particulier etre 
informe sur l’origine du projet, le champ couvert, les structures concemees, les 
resultats d’eventuelles etudes anterieures, l’etat de l’application existante, les 
contraintes. 

L’etat final correspond aux objectifs vises et resultats attendus par le client. 


16.3.3 Les fournitures relatives au domaine cible 

Les fournitures relatives au domaine cible sont soit des fournitures qui decrivent 
le systeme d’information (modeles, rapports, specifications...), soit des elements 
operationnels (modules, application...) qui relevent du systeme informatique. 
Dans la perspective d’une approche agile, on mettrait aujourd’hui l’accent sur les 
livraisons de composants logiciels. 


16.3.4 Les fournitures du domaine projet 

Euromethode distingue deux sous-categories : les plans de projet et les comptes 
rendus de projet. 

Les fournitures relatives aux plans de projet permettent de controler le 
processus de production interne, de s’assurer que les objectifs sont atteints et 
de definir le niveau de qualite necessaire pour les fournitures du domaine 
cible. Le plan de projet fait reference a des fournitures decrites dans le plan de 
livraison. 

Les fournitures relatives au compte rendu de projet sont utilisees pour evaluer 
l’adequation des fournitures du domaine cible ainsi que leur contenu, pour 
determiner si les exigences definies pour le processus sont satisfaites et pour 
documenter la fagon dont les activites prevues par les plans ont ete accom- 
plies. 
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Le referential PRINCE2 1 ( PRojects IN Controlled Environments ) a ete comman- 
dite par le gouvemement britannique, a l’origine pour les projects publics. Repris 
plus largement dans le secteur prive, en Grande-Bretagne d’abord, puis en 
Europe, il donne aujourd’hui lieu a une certification. Son objectif majeur est de 
reduire les risques des projets, par une maitrise accrue. 

Le referential presente un modele des processus qui doivent etre mis en 
oeuvre pour maitriser la conduite du projet (figure 16.3). 



Figure 16.3 — Modele des processus de PRINCE2. 


« Demarrer le projet » correspond au lancement et n’intervient qu’une seule 
fois dans le cycle de vie du projet. 

« Diriger le projet » interagit avec tous les autres processus durant toute la 
duree du projet. Ce processus est place sous la responsabilite du comite de direc- 
tion du projet. 

« Commencer le projet » n’est execute qu’une seule fois dans le cycle de vie 
d’un projet. II vise a produire un premier document de management de projet 
qui comprend notamment les objectifs du projet, le contenu du projet, les livra- 
bles, ainsi que l’organisation du projet et un debut de plan de management de 
projet (cf. § 6.3). 


1. http://www.prince2.com/ 
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« Planifier » est un processus commun pour la planification des differents 
aspects du projet. 

« Controler une etape » est un processus iteratif, qui est repete pour chacune 
des etapes du cycle de vie du projet. II guide le chef de projet dans son pilotage 
au quotidien. 

«Gerer la livraison du produit » propose un mecanisme pour suivre la produc- 
tion depuis l’affectation des taches jusqu’a la foumiture du livrable correspon- 
dant. 

«Gerer les frontieres de 1’ etape » permet de gerer la transition d’une etape a 
l’autre, et inclut la capitalisation d’experience. 

« Clore le projet » est le processus qui officialise l’achevement du projet. 

Par ailleurs, PRINCE2 decrit huit « composants », auxquels sont attaches des 
connaissances qui seront mises en oeuvre dans les differents processus de mana- 
gement de projet. On y retrouve des aspects classiques : gestion des risques, 
gestion de la qualite, pilotage du projet... Citons en particulier Business case, 
composant qui oriente tout le projet, dans le sens ou il decrit les attentes metier 
liees au projet et sert de base aux revues du projet. 

Le referentiel n’est pas en contradiction avec le referentiel du PMI presente 
au chapitre 17. II est globalement moins complet que le PMBOK et parfois plus 
directif. II foumit un ensemble de documents types qui peuvent etre utilises dans 
l’administration d’un projet. 
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de la certification PMI 


17.1 LA CERTIFICATION DU PMI 

17.1.1 LechoixduPMI 

La certification en management de projet rencontre un interet croissant depuis 
quelques annees. Nous avons indique au debut de cet ouvrage (paragraphe 1.1) 
l’existence d’organisations professionnelles delivrant des certifications. Aujourd’hui, 
on peut hesiter entre deux certifications Internationales : celle de 1’IPMA (Inter- 
national Project Management Association), axee sur la reconnaissance des com- 
petences du candidat a exercer correctement la fonction de chef de projet ou 
directeur de projet (paragraphe 1.3.2) ; et celle du PMI ( Project Management 
Institute ) qui repose sur la validation de la comprehension et l’assimilation des 
connaissances de reference. Cet ouvrage etant consacre aux principes et techni- 
ques de management de projet, nous avons fait le choix de proposer une solide 
introduction pour ceux qui, se rattachant au domaine des systemes d’informa- 
tion, ont l’objectif d’obtenir une certification PMI. 

Pour cela, nous avons d’abord expose les regies de la certification. Ensuite, 
nous decrivons les concepts cles et la logique propre au PMI, qui ne contredisent 
pas l’ensemble de ce qui figure de fagon detaillee dans cet ouvrage. Enfin, nous 
reprenons les differents aspects du management d’un projet avec la terminologie 
PMI et nous etablissons une correspondance avec les techniques exposees en 
detail et illustrees dans les deux premieres parties. 


77 . La preparation de la certification PMI 



17.1.2 L'apport a la preparation de la certification 

Ce chapitre 17 se veut une presentation claire et structuree de la demarche un 
peu abstraite portee par PMI. Ses principes et sa logique apparaitront plus facile- 
ment au lecteur deja averti par son parcours dans nos deux premieres parties. 

II est egalement possible de lire cet ouvrage en enchamant les chapitres 1 et 17, 
et en se reportant ensuite aux chapitres intermediaires en fonction des renvois aux 
techniques particulieres indiquees dans les paragraphes 17.4 a 17.12 ci-dessous. 

Apres lecture du chapitre 17, le lecteur pourra aborder de fagon efficiente et 
efficace l’etude du document de reference du PMI, accompagne eventuellement 
d’un ouvrage specialise et de preference en s’appuyant sur une base de simulation 
de tests qui permet de se familiariser avec la duree imposee et le style des ques- 
tions posees. Certains titres choisis (ouvrage et logiciel) sont donnes dans la 
bibliographie en annexe 


1 7.2 LE CADRE DE LA CERTIFICATION DU PMI 

17.2.1 Le referentiei 

L’examen de certification du PMI s’appuie sur le PMBOK, Project Management 
Body of Knowledge, qui rassemble un ensemble de connaissances ayant fait l’objet 
d’une large reconnaissance. Les principes et techniques exposes sont applicables 
a la majorite des projets et leur mise en oeuvre devrait ameliorer les chances de 
succes des projets. Cependant, le referentiei du PMI n’offre pas, sauf exception, 
de description des. techniques de management de projet recommandees. 

Par ailleurs, le referentiei est general et n’introduit pas certaines particularites 
liees a des caracteristiques du projet, notamment le domaine d’ application. Or, si 
certaines techniques sont communes a tous les projets (techniques de planification 
des delais, par exemple), d’autres se declinent de flagon specifique selon le domaine 
(techniques d’estimation de la charge de travail, par exemple). Dans ce chapitre, 
nous mettons en relation les techniques generiques indiquees par le PMBOK et 
les techniques applicables aux projets de systeme d’ information decrites dans les 
huit premiers chapitres de cet ouvrage. 

La version en cours du PMBOK est la 3 e et elle date de 2004. Elle a fait l’objet 
de traduction en differentes langues, dont le franqais. 

17.2.2 L’examen de certification 

Le PMI propose deux types de certification : PMP, Project Management Professional, 
et CAPM, Certified Associate in Project Management. 
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Pour obtenir la certification PMP, qui est la plus repandue actuellement, il 
faut d’abord soumettre une demande d’eligibilite. Pour etre accepte, il faut satis- 
faire a deux exigences : d’une part, avoir suivi au mo ins 35 heures de cours en 
management de projet : d’autre part, faire etat d’experiences de travail en mode 
projet dont la duree est variable selon le niveau d’etudes (trois annees durant les 
six demieres annees si l’on est titulaire d’un diplome d’enseignement superieur, 
ou cinq annees durant les 8 demieres annees sinon). La demande s’effectue par 
internet aupres du siege americain de l’association, et la reponse est envoyee au bout 
de quelques jours. Il s’agit alors de s’inscrire aupres d’un des centres d’examen 
habilites. L’epreuve est individuelle et informatisee : elle comporte 200 questions a 
choix multiples, aussi bien a caractere theorique que portant sur des mises en 
situation, et le temps imparti est de quatre heures. Les questions, qui sont les 
memes quel que soit l’endroit du globe ou Ton se presente, sont redigees en 
anglais, mais une traduction peut etre affichee sur commande. 

Le PMI propose egalement une certification CAPM qui est destinee aux assis- 
tants du chef de projet. Le referentiel est le meme, mais l’examen ne comporte 
que 150 questions, plutot theoriques, et se deroule sur trois heures. 


17.3 LA LOGIQUE GENERALE DU PMBOK 

173.1 La structure du PMBOK et les domaines de connaissance 

Le guide du PMBOK comprend trois chapitres introductifs qui presentent les 
notions cles, notamment la distinction entre le projet et le produit, le principe 
de structuration temporelle du projet et l’architecture des connaissances concer- 
nant les activites de management de projet. Celles-ci sont organisees en proces- 
sus, selon la preconisation de la norme IS09000 et IS010006 (Cf. paragraphe 
16.2). Les processus sont regroupes autour de huit points de vue devant etre pris 
en compte dans la gestion d’un projet : le contenu, les delais, les couts, la qualite, 
les ressources humaines, les communications, les risques, les approvisionne- 
ments, ainsi qu’un point de vue integrateur ou peuvent se faire les syntheses et 
les arbitrages. 

Ces neuf points de vue, appeles « domaine de connaissance », component 
plusieurs processus. Chaque processus est decrit selon la structure de la figure 
17.1, c’est-a-dire comme une boite noire visant a produire des sorties a partir 
de certaines entrees (pouvant etre elles-memes des sorties d’un autre processus) 
en utilisant eventuellement des outils (moyens tangibles, par exemple logiciel) 
ou des techniques (activites organisees de fagon procedural pour resoudre un 
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probleme ou apporter une aide, par exemple technique de calcul de la perfor- 
mance du projet) : 



OUTTLS ET 

w QOTPTTThQ 


TECHNIQUES 

“ 1 oUK 1 luo 


Figure 17.1 — Structure de description d’un processus dans le PMBOK. 

17.3.2 Produit et projet 

Le produit est un terme qui prend deux significations differentes selon le niveau 
auquel on se situe. A un niveau generique, il designe le resultat vise par le projet. 
De fagon plus detaillee, un produit peut prendre trois formes differentes : ce peut 
etre un produit (dans le deuxieme sens), c’est-a-dire un artefact utilisable qui 
possede une certaine materialite (par exemple, un objet ou un logiciel) ; ce peut 
aussi etre un service, c’est-a-dire l’accomplissement d’un travail utile (par exem- 
ple, la formation des utilisateurs) ; ce peut enfin etre un resultat, c’est-a-dire un 
element issu du projet et pouvant etre constate (par exemple, l’integration de 
deux applications ou un document d’etude). 

Le produit, dans le sens generique, doit etre soigneusement distingue du 
projet, notamment lorsque Ton parle de contenu. Le contenu du produit, dont la 
description est de la responsabilite du commanditaire du projet, renvoie aux 
caracteristiques et specifications du produit/service/resultat demande. Le contenu 
du projet, qui est identifie par l’equipe de projet, comprend le travail necessaire 
pour obtenir le produit vise. 

Le passage du contenu du produit au contenu du projet s’effectue schemati- 
quement en quatre etapes, qui peuvent se derouler de fagon cyclique : 

1 . Le commanditaire elabore une Description du contenu du produit, c’est-a- 
dire une description, parfois succincte, de ce qui est attendu. Cette 
description peut etre enrichie au cours du projet. Si la description est 
susceptible d’evoluer profondement, il est recommande de mettre en 
place une Gestion de configuration, c’est-a-dire une procedure d’enregistre- 
ment des caracteristiques du produit et de chacune des modifications. 

La description du contenu du produit fait en general partie d’un document 
plus global, foumi en entree du projet et appele Enonce des travaux du 
projet, qui comporte notamment des elements sur le contexte du projet. Le 
commanditaire peut ainsi indiquer les raisons qui ont conduit au lancement 
du projet et sa contribution au plan strategique de l’entreprise. 

2. L’equipe de projet va alors traduire, avec l’accord du commanditaire, le 
contenu du produit en livrables, c’est-a-dire en elements precisant le produit 
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demande et pouvant faire l’objet d’une verification. Lorsque le comman- 
ditaire constatera officiellement la realisation satisfaisante de tous les livrables 
du projet, celui-ci sera considere comme acheve. 

Certains livrables peuvent etre lies au management de projet, par exemple 
la situation financiere du projet a la fin de chaque mois. 

A ces livrables « extemes » viennent parfois s’ajouter des livrables « inter- 
nes » visibles uniquement par Tequipe de projet. 

3. Lorsque les livrables sont clairement identifies, Tequipe de projet deter- 
mine les travaux a realiser pour les obtenir et les consignes avec la liste 
des livrables dans un Enonce du contenu du projet. Ce document, qui 
mentionne egalement les contraintes (budget, delai, ressources) et certaines 
exigences (securite, performance), constitue une reference commune et 
va guider le travail de Tequipe de projet. 

4. Dans un dernier temps, Tequipe de projet planifie le travail a realiser en 
elaborant une SDP, Structure de decoupage du projet (aussi appelee WBS, 
Work Breakdown Structure ), c’est-a-dire une decomposition hierarchique, 
guidee par les livrables a produire, des travaux a realiser a une maille 
parfois plus fine que celle de TEnonce du contenu du projet. On appelle 
lot de travail le niveau de decomposition le plus bas de la SDP. 

Celle-ci est la reference pour la planification et le suivi. Les logiciels de 
gestion de projet proposent de gerer des codes hierarchises permettant des 
regroupements dans les etats de suivi des delais ou des couts. 

17.3.3 Les phases et le cycle de vie du projet 

Les travaux identifies dans la SDP vont ensuite etre organises dans le temps, a 
deux principaux niveaux. Au niveau le plus detaille, ils vont etre ordonnances, 
et eventuellement donner lieu a des calculs de chemin critique. On peut parfois, 
a un niveau plus global, regrouper ces travaux en phases pour placer des jalons 
dans le deroulement du projet et reduire ainsi l’incertitude. Celles-ci sont des 
ensembles d’activites, debouchant sur un ou plusieurs livrables importants. La 
phase prend parfois le nom du livrable principal, par exemple Phase de Concep- 
tion. Le contenu du projet apparait alors comme structure en phases qui sont 
generalement effectuees de fagon sequentielle. 

Le cycle de vie du projet est l’ensemble des phases d’un projet, s’il en comporte 
plusieurs. Une phase s’acheve, en general, par une revue du travail accompli et 
des livrables, a Tissue de laquelle on decide de clore le projet ou de demarrer la 
phase suivante. 

Une approche alternative au phasage peut etre de distinguer plusieurs projets 
consecutifs. Devaluation de Tincertitude guide le choix entre les deux options. Par 
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exemple, si le projet commence par une Etude de faisabilite et que la suite est tres 
incertaine, on preferera en faire un projet complet avec une phase unique. Si au 
contraire, la suite est tres probable, ce sera la premiere phase du cycle de vie d’un 
projet global. 

Le cycle de vie du projet peut representer une etape dans ce que Ton appelle 
le « cycle de vie du produit ». Par exemple, un systeme d’information commence 
a vivre des son identification dans un plan strategique jusqu’a l’abandon de 
l’application correspondante : le passage correspondant a la conception et mise 
en oeuvre d’une nouvelle application (ou d’un nouveau progiciel) se fait sur le 
mode d’un projet avec son cycle de vie (figurel7.2). 


Cycle de vie du s.i. 



Figure 1 7.2 — Cycle de vie du projet et cycle de vie du produit. 

Les modeles de developpement decrits au chapitre 2 representent des modeles 
de cycle de vie d’un projet. 

17.3.4 Les processus de management de projet et les groupes 
de processus 

Le Guide du PMBOK propose une repartition des activites de management de 
projet en 44 processus, lies entre eux via les donnees d’entree et de sortie et 
repartis dans les 9 domaines de connaissance presentes au paragraphe 17.3.1. Ils 
font l’objet d’une seconde categorisation, orthogonale a celle des domaines de 
connaissances et basee sur une logique sequentielle : les groupes de processus. 

Les groupes de processus sont lies entre eux par une dependance logique 
forte. Ils structurent la gestion de chacune des phases du projet. On distingue 
cinq groupes. Le groupe Demurrage comprend les processus a executer en debut 
de chaque phase du projet dans le but d’autoriser officiellement le demarrage des 
travaux (par exemple elaborer une premiere version de l’Enonce du contenu du 
projet). Le groupe Planification rassemble les processus de tous les domaines de 
connaissances qui visent a planifier les actions requises, sous un angle ou un autre 
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(contenu, cout, delais, ressources humaines, qualite, etc.)- Le groupe Execution 
comprend ceux des processus qui visent a faire realiser les travaux prevus (affec- 
tation des ressources, selection d’un sous-traitant, etc.). Le groupe Surveillance et 
Maitrise sont les processus de pilotage du projet, qui permettent de surveiller les 
ecarts entre le planifie et le reel et de prendre eventuellement des mesures 
correctives (par exemple, verifier le contenu ou etablir un rapport d’avance- 
ment). Le groupe Cloture vise a formaliser l’achevement d’une phase. 

En principe, pour la gestion de chacune des phases, on retrouve au moins un 
processus de chaque groupe dans l’ordre presente a la figure 17.3 : les processus de 
Demarrage et de Cloture ne sont executes qu’une seule fois, alors que l’on peut 
avoir plusieurs cycles de processus de Planification - Execution - Surveillance et 
Maitrise. 


Management d’une phase du projet 



Figure 17.3 — Sequencement des groupes de processus d’une phase. 


Au-dela de cet ordonnancement global, les processus de chaque groupe posse- 
dent certains liens, que nous allons evoquer. Pour ce faire, nous avons utilise la 
codification du PMBOK, qui attribue a chacun des 9 domaines de connaissance le 
numero du chapitre dans lequel il est presente : 

• 4 = Management de l’integration du projet 

• 5 = Management du contenu du projet 

• 6 = Management des delais du projet 

• 7 = Management des couts du projet 

• 8 = Management de la qualite du projet 

• 9 = Management des ressources humaines du projet 

• 10 = Management des communications du projet 

• 11 = Management des risques du projet 

• 12 = Management des approvisionnements du projet. 
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Chaque processus est ensuite numerote sequentiellement a l’interieur du 
domaine. 

Le groupe Demarrage comporte les processus 4.1 et 4.2 du domaine 4 (inte- 
gration) (figure 17.4). 



Figure 1 7.4 — Les processus du groupe Demarrage. 


Le groupe Planification comporte vingt-et-un processus des neuf domaines 
(figure 17.5), ce qui signifie que tous les aspects d’un projet sont planifies. 

II convient de souligner que la demarche de planification n’est pas totalement 
lineaire : non seulement la planification du contenu interagit avec la definition 
du contenu, mais la planification de certains aspects (risques ou approvisionne- 
ments par exemple) peut conduire a faire evoluer le budget initial. Par ailleurs, 
on peut relever une legere difference entre cette dynamique generale de planifi- 
cation et celle qui est generalement mise en oeuvre dans les projets de systeme 
d’information ou les couts majeurs (et les plus fortement entaches d’incertitude) 
sont ceux de matiere grise. C’est pourquoi, comme cela a ete expose dans la 
premiere partie de cet ouvrage, le plus souvent on estime d’abord la quantite de 
travail, qui correspondra a un cout apres affectation a une ressource ou une 
ressource-type. Au niveau d’une activite elementaire la quantite de travail equi- 
vaut a la duree compte tenu de la difficult^, sauf exception, a diviser un travail 
de production intellectuelle entre plusieurs personnes. 

Le groupe Execution comporte sept processus des domaines 4 (integration), 
8 (qualite), 9 (ressources humaines), 10 (communications) et 12 (approvision- 
nements) (figure 17.6). 

Le groupe Surveillance et Maitrise comporte douze processus des neuf 
domaines de connaissances (figure 17.7). La logique generale est la suivante : 
tous les aspects d’un projet sont mis sous controle, notamment les modifications 
survenues ou demandees. Comme la modification d’un aspect (contenu, risque, 
etc.) peut avoir des repercussions sur les autres (couts, equipe, etc.), il s’agit de 
rechercher une coherence et un equilibre de l’ensemble du projet. 

Le groupe Cloture comporte deux processus des domaines 4 (integration) et 
12 (approvisionnements) (figure 17.8). La phase — ou le projet si Ton est dans 
le cas d’une phase unique ou d’une phase finale — fait l’objet d’une fermeture 
officielle, qui inclut le cas echeant les activites de solde du contrat. 
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Figure 17.5 — Les processus du groupe Planification. 
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Figure 17.6 — Les processus du groupe Execution. 



Figure 17.7 — Les processus du groupe Surveillance et MaTtrise. 
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Figure 17.8 — Les processus du groupe Cloture. 

Nous allons maintenant reprendre les 44 processus en les presentant par 
domaine de connaissances et en rappelant leur appartenance a un groupe de 
processus. L’objectif est d’indiquer les techniques utilisables dans l’execution de 
chaque processus en renvoyant a la description correspondante dans la premiere 
partie de cet ouvrage. 


17.4 LE MANAGEMENT DE ^INTEGRATION DU PROJET 

17.4.1 Les processus du management de I’ integration 

L’objectif commun de ces processus est de prendre en compte toutes les dimen- 
sions du projet durant sa vie. 

II s’agit d’abord de lancer officiellement le projet, ce qui releve en general du 
commanditaire et peut se materialiser par une charte par laquelle le chef de 
projet est officiellement nomme. Ensuite, un premier enonce du contenu du 
projet avec les principaux livrables (paragraphe 17.3.2) est elabore. Le resultat 
de la planification des differents aspects vient alimenter un plan de management 
de projet, pouvant etre structure selon les domaines de connaissances, et decrit 
au paragraphe 6.3. Ce plan est execute par l’equipe de projet. Regulierement, 
l’equipe de management de projet calcule les performances et les eventuelles 
modifications (faites ou a faire) sont prises en compte selon une vision globale 
du projet. A l’achevement, le projet est clos officiellement. 

La figure 17.9 recapitule ces processus, classes par groupe d’appartenance. 


Demarrage 

Planification 

Execution 

Surveillance 
et maitrise 

Cloture 

4.1. Elaborer la 
charte du projet 

4.2. Elaborer 
l’enonce prelimi- 
naire du contenu du 
projet 

4.3. Elaborer le 
plan de manage- 
ment de projet 

4.4. Diriger et 
piloter 1’ execu- 
tion du projet 

4.5. Surveiller et 
maitriser le travail 
du projet 
4.6 Maitrise inte- 
gree des modifi- 
cations 

4.7. Clore 
le projet 


Figure 17.9 — Les processus de management de I'integration. 


77. La preparation de la certification PMI 



17.4.2 Les techniques utiles pour le management de i’integration 

Dans le processus 4.1, on peut utiliser pour arbitrer entre deux scenarios du 
meme projet la technique du retour sur investissement (ROI) ou celle de la 
valeur monetaire attendue (VMA) decrites au chapitre 7 et illustrees au chapitre 12. 

Un tableau de bord tel que celui expose dans les paragraphes 12.3 a 12.10 
peut etre utilise dans les processus 4.4 et 4.5. 

Dans le processus 4.5, on peut egalement utiliser, pour evaluer la performance 
et calculer les previsions, les indicateurs de la technique de la valeur acquise 
(EVT), decrite au chapitre 7 et illustree au chapitre 12. 

Notons enfin qu’un outil de planification et suivi du projet, tel que celui 
decrit au chapitre 15, peut etre utilise dans tous les processus du management de 
l’integration. 


17.5 LE MANAGEMENT DU CONTENU DU PROJET 

175.1 Les processus du management du contenu du projet 

L’objectif commun de ces processus est de mettre en place un dispositif pour 
definir et executer uniquement les activites necessaires pour achever le projet de 
fapon satisfaisante. 

Pour cela, on definit d’abord comment on va s’organiser pour gerer le 
contenu, puis on elabore un enonce detaille du contenu du projet, c’est-a-dire 
du travail necessaire (paragraphe 17.3.2) et on cree la structure de decoupage du 
projet (SDP) comme decrit au paragraphe 2.2. Le niveau de decomposition vise 
est celui des lots de travail, tel que presentes au paragraphe 17.3.2. 

Apres realisation des livrables, on officialise leur acceptation, et le cas 
echeant on prend en compte les modifications de contenu qui seront ensuite 
traitees par le processus de Maitrise integree des modifications. 

La figure 17.10 recapitule ces processus, classes par groupe d’appartenance. 


Demarrage 

Planification 

Execution 

Surveillance et maitrise 

Cloture 


5.1. Planification du contenu 

5.2. Definition du contenu 

5.3. Creer la structure de 
decoupage du projet 


5.4. Verification du 
contenu 

5.5. Maitrise du con- 
tenu 



Figure 17.10 — Les processus de management du contenu. 
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1 7.5.2 Les techniques utiles pour le management du contenu du projet 

Pour bien cemer les caracteristiques du projet dans le processus 5.2, on peut utili- 
ser 1’ analyse des parties prenantes, dont la notion a ete introduite au chapitre 5 
et la technique illustree au chapitre 13. 

Dans le processus 5.3, on peut elaborer le decoupage du travail en s’appuyant 
sur les approches de structuration et modeles de developpement presentes tout 
au long du chapitre 2. 

Le processus 5.5 peut faire intervenir un Systeme de gestion de configuration 
(paragraphel7.3.2) si les modifications sont frequentes et importantes. 


17.6 LE MANAGEMENT DES DELAIS DU PROJET 

17.6.1 Les processus du management des delais du projet 

L’objectif commun de ces processus est de s’organiser pour achever le projet en 
temps voulu. 

II s’agit d’abord de completer la definition du contenu du projet en identifiant 
le plus finement possible les activites necessaires pour produire les livrables, puis 
de reperer les dependances entre ces activites, qu’elles soient dues a la nature du 
travail, a des choix de l’equipe ou a des contraintes exterieures. On estime d’une 
part les types et quantites de ressources necessaires et d’autre part la duree des 
activites. On peut alors elaborer le calendrier du projet qui servira de reference. 
Les ecarts par rapport a cet echeancier de reference seront detectes, voire anticipes, 
et pourront donner lieu a des recommandations de modification du calendrier 
pour que celles-ci soient prises en compte de fagon integree, en considerant les 
autres aspects du projet. 

La figure 17.11 recapitule ces processus, classes par groupe d’appartenance. 


Demarrage 

Planification 

Execution 
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et maitrise 
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6.1. Identification des activites 

6.2. Sequencement des activites 

6.3. Estimation des ressources 
necessaires aux activites 

6.4. Estimation de la duree des 
activites 
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cier 



Figure 17.11 — Les processus de manasement des delais. 
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17,6.2 Les techniques utiles pour ie management des delais du projet 

Pour identifier les activites elementaires (processus 6.1 ), on reprend la Structure 
de Decoupage du Projet (SDP) et on decompose chaque lot de travail. On peut 
utiliser modeles de decomposition par exemple un lot de type « Realisation » 
comprend de fagon standard les activites d’elaboration de jeu d’essai, d’etude 
technique, de programmation et de test unitaire. Sur les projets de taille impor- 
tante, on recourt generalement a la « planification par vagues », c’est-a-dire que 
l’on n’identifie les activites elementaires que pour les lots de travail devant etre 
planifies a court terme. 

Pour sequencer les activites ( processus 6.2), on utilise de fagon generale la tech- 
nique des graphes permettant de representer les liens logiques et les contraintes 
d’enchainement. II en existe differentes formes, dont les deux principales ont ete 
introduces au paragraphe 4.2 : le diagramme des antecedents (de loin le plus 
utilise et parfois connu sous le nom de PERT) et le diagramme fleche. 

Les liens entre activites peuvent etre documentes selon l’origine : une depen- 
dance obligatoire, parfois appelee dependance logique forte, est inherente a la 
nature des activites ; une dependance optionnelle, ou lien logique prefere, est 
decidee par l’equipe de management de projet, souvent a partir d’experiences 
anterieures ; une dependance exteme est une contrainte liee a des activites exte- 
rieures au projet, par exemple une date imposee. 

Sur chaque lien, on peut appliquer des avances ou des retards (paragraphe 4.3). 

Pour estimer les ressources necessaires (processus 6.3), on peut utiliser une 
methode relevant de ce que Ton appelle l’« estimation ascendante », qui consiste 
obtenir une estimation en totalisant les charges estimees des composants (lot de 
travail, activite, tache. . . ). Son application requiert une definition precise du travail. 
On en a vu deux exemples au chapitre 3 : la methode devaluation analytique 
(paragraphe 3.6) et la generalisation de l’approche par unite d’oeuvre (para- 
graphe 3.10). On peut aussi s’appuyer sur le jugement d’expert, eventuellement 
avec la methode Delphi (paragraphe 3.4). 

Parfois, on souhaite comparer deux scenarios (par exemple en sous-traitant 
une partie) sous Tangle des ressources necessaires : on peut alors appliquer la 
technique de la Valeur Monetaire Attendue (VMA) decrite au chapitre 7 et illustree 
au chapitre 12. 

L’estimation de la duree des activites (processus 6.4) fait appel a toutes les 
techniques du chapitre 3, avec les appellations generiques suivantes. 

L’estimation dite « par analogie », ou « evaluation descendante », consiste a 
utiliser les couts reels de projets anterieurs similaires comme base d’ estimation 
des totaux des couts d’un projet en cours, ce qui implique d’avoir capitalise. Ces 
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methodes sont adequates lorsque Ton dispose de peu d’informations sur le projet ou 
que Ton est dans un cadre normatif. On a vu l’exemple de la methode de repartition 
proportionnelle (paragraphe 3.5.1) et la methode des ratios (paragraphe 3.5.2). 

L’estimation dite « parametrique » correspond a la famille des methodes 
basees sur une unite d’oeuvre. On en a vu deux exemples : le modele Cocomo 
(paragraphe 3.7) et la methode des points de fonction (paragraphe 3.8). 

Si l’incertitude sur les valeurs estimees est elevee, on peut utiliser l’estimation 
a trois points (valeur optimiste, valeur pessimiste, valeur la plus probable) et pren- 
dre la moyenne, ponderee ou non, comme on l’a vu au paragraphe 3.9. Signalons 
que dans les appellations recentes, on appelle reseau PERT un diagramme des 
antecedents sur lequel on a utilise des estimations de duree calculees ainsi : 

[(estimation optimiste + estimation pessimiste 
+ 4*(estimation la plus probable)]/6 

On peut egalement faire une provision pour d’eventuels aleas, en pourcen- 
tage de la valeur estimee ou en nombre de jours, que Ton appelle « reserve de 
temps » ou « tampon ». 

Pour elaborer l’echeancier (processus 6.5) et produire un diagramme a barres, tel 
que le diagramme de Gantt presente au paragraphe 4.5, on efifectue une analyse du 
graphe des activites, represente le plus souvent par un diagramme des antecedents. 
La technique la plus connue est celle du chemin critique, avec les dates au plus tot, 
dates au plus tard, marge totale et marge libre, tel que detaille au paragraphe 4.4. 

On peut alors decider d’introduire des modifications, notamment de compresser 
l’echeancier pour reduire le delai global. Ceci peut se faire en reduisant la duree 
des activites, notamment celles qui se trouvent sur le chemin critique : c’est ce 
que les Anglo-Saxons appellent le « crashing ». On peut egalement utiliser 
l’execution acceleree par chevauchement, « fast tracking », qui consiste a faire 
executer en parallele des phases ou des activites qui devraient normalement se 
derouler en sequence. La compression de l’echeancier peut augmenter les couts, 
que ce soit ceux d’une coordination accrue ou ceux lies a une non-qualite des 
resultats et a l’obligation de reprise. 

On fait parfois une analyse des eventualites, c’est-a-dire que Ton teste plusieurs 
scenarios de delai, soit en considerant un evenement particulier (par exemple, 
retard dans le demarrage d’une tache a cause de la defaillance d’un sous-trai- 
tant), soit en s’appuyant sur des distributions de probabilites. La methode de 
Monte-Carlo s’inscrit dans ce deuxieme cas et fonctionne de la faqon suivante : 
on suppose que Ton connait la fonction des probabilites de durees possibles de 
chaque activite (par exemple une courbe de Gauss entre une valeur minimale, 
une valeur maximale et une valeur moyenne). On effectue de nombreuses itera- 
tions du calcul de la duree totale du projet, en tirant au hasard une valeur de la 
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duree de chaque activite en fonction de la loi de distribution qui lui est attachee. 
On dispose ainsi d’un ensemble de durees calculees du projet, dont on va prendre 
la moyenne (paragraphe 3.9). 

Apres stabilisation du diagramme des antecedents, on fait des hypotheses sur 
la disponibilite des ressources. Cela peut conduire a ne pas utiliser toutes les 
possibilites de parallelisme. Le PMBOK parle de nivellement dans deux cas : soit 
parce le nombre de personnes dans l’equipe doit etre maintenu au-dessus d’un 
certain niveau (ce qui est l’emploi classique du terme), soit parce que Ton doit 
resoudre des problemes d’indisponibilites partielles, par exemple une ressource 
rare et affectee a des taches en parallele ou bien une ressource partagee. On a 
presente cette technique sous le terme souvent utilise de lissage (paragraphe 4.6.4). 

La methode dite de la chaine critique est due a E.M. Goldratt, qui preconise 
de se focaliser sur une chaine critique qui est composee des activites pouvant 
etre des goulets d’etranglement, soit qu’elles soient porteuses d’une incertitude 
elevee, soit qu’elles soient affectees a des ressources rares dont l’indisponibilite 
pourrait avoir un impact important. Au lieu de saupoudrer de la marge sur la 
plupart des activites, il est preferable de planifier au plus tard et de raj outer des 
taches-tampons apres les activites de la chaine critique, ou en fin de phase pour 
absorber des retards (paragraphe 4.6.2). 

Le calendrier du projet est ensuite represente, eventuellement a l’aide d’un 
outil de planification, sous forme d’un diagramme de Gantt (paragraphe 4.5). 

Pour suivre les delais et controler les ecarts (processus 6.6), on s’appuie sur un 
tableau de bord, par exemple un recapitulatif produit chaque semaine, sur les 
indicateurs de la valeur acquise, notamment l’ecart de delai, l’indice de perfor- 
mance requis et les previsions a l’achevement (paragraphe 7.3). Les logiciels de 
suivi de projet foumissent egalement des tableaux de suivi de performance et des 
diagrammes a barre dans lesquels figurent la planification de reference et les 
performances reelles (paragraphe 15.4). 


1 7.7 LE MANAGEMENT DES COUTS DU PROJET 

77.7.7 Les processus du management des couts du projet 

L’objectif commun de ces processus est de s’organiser pour que le projet soit realise 
dans les limites d’un budget impose ou negocie. 

II s’agit de determiner une valeur approximative des couts des activites et 
d’etablir un budget, c’est-a-dire un cout global du projet par agregation des couts 
des activites. La maitrise des couts suppose le suivi des depenses et la connais- 
sance de leur origine : les ecarts par rapport au budget sont alors detectes, voire 
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anticipes, et peuvent donner lieu a des recommandations ou propositions de 
modifications qui seront traitees de fagon integree. 

La figure 17.12 recapitule ces processus, classes par groupe d’appartenance. 
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Figure 17.12 — Les processus de management des couts. 


17 . 7.2 Les techniques utiles pour ie management des couts du projet 

L’estimation des couts ( processus 7.1 ) etant souvent Lee a l’estimation de la 
quantite de travail necessaire, on retrouve certaines techniques deja mentionnees 
pour les processus 6.3. (estimation des ressources) et 6.4 (estimation des durees). 
En particulier, l’estimation par analogie (par ex. la repartition proportionnelle), 
I’estimation ascendante (par ex. revaluation analytique) et l’estimation para- 
metrique (par ex. les points de fonctions). 

Comme pour les delais, on peut prevoir une enveloppe financiere pour 
d’eventuels aleas, si le budget l’autorise. 

L’etablissement du budget de reference (processus 7.2) peut, notamment si l’on 
n’est pas passe par une estimation des activites ou pour conforter cette demiere, 
etre effectuee au moyen d’une methode parametrique : on repartira ensuite ce 
cout global entre les differentes activites. 

La maitrise des couts (processus 7.3) s’appuie essentiellement sur l’etablisse- 
ment et l’analyse des indicateurs de performance, en particulier ceux foumis par 
la technique de la valeur acquise (paragraphe 7.3). 


17.8 LE MANAGEMENT DE LA QUALITE DU PROJET 

17.8.1 Les processus du management de la qualite du projet 

L’objectif commun de ces processus est de s’organiser pour mettre en oeuvre des 
actions visant la qualite du processus projet, ainsi que celle du produit vise. 

Pour cela, on va elaborer un plan qualite qui viendra s’inserer dans le plan de 
management de projet, indiquant d’une part les actions et dispositions pour 
donner confiance dans la qualite du processus, d’autre part les criteres qualite du 
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produit explicites avec le commanditaire. Ensuite, on verifie periodiquement que 
l’equipe de projet effectue les activites de gestion de la qualite conformement au 
plan qualite), et on controle la qualite des resultats du projet avant livraison. 

La figure 17.13 recapitule ces processus, classes par groupe d’appartenance. 
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Figure 17.13 — Les processus de management de la qualite. 


1 7.8.2 Les techniques utiles pour le management de la qualite du projet 

La planification de la qualite (processus 8.1 ) s’appuie sur les principes qualite, 
notamment les facteurs et indicateurs qualite (paragraphe 8.5) et le contenu 
d’un plan qualite (paragraphe 8.7). 

La mise en oeuvre de l’assurance qualite ( processus 8.2) consiste a verifier que 
les dispositions prevues sont effectivement appliquees. Elle porte done sur les 
processus de management du projet. La technique principalement utilisee est l’audit 
qualite (paragraphe 8.8.2), e’est-a-dire une revue structuree et independante de 
la fagon dont le travail est organise et effectue, qui peut deboucher sur des 
recommandations de correction ou d’ amelioration. 

Le controle qualite (processus 8.3) porte sur les resultats du projet : il consiste 
a verifier qu’ils sont bien conformes aux normes et criteres qualite retenus (para- 
graphe 8.8.1). II s’applique bien entendu aux livrables, mais egalement aux docu- 
ments produits par le management de projet. 


1 7.9 LE MANAGEMENT DES RESSOURCES HUMAINES DU PR01ET 

17.9.1 Les processus du management des ressources humaines 
du projet 

L’objectif commun de ces processus est d’organiser et gerer l’equipe de projet 
afin d’obtenir l’engagement de chacun dans le projet. 

Pour cela, il s’agit definir les roles (responsabilites d’activites et autorite even- 
tuelle) et d’obtenir le personnel pouvant assurer ces roles. Puis, on cherche a etablir 
et maintenir une bonne collaboration et un climat positif dans l’equipe, par des 
mesures individuelles ou concemant tout le groupe. Par ailleurs, les performances 
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font l’objet d’un suivi, qui permet parfois d’identifier des problemes qui doivent 
etre geres. 

La figure 17.14 recapitule ces processus, classes par groupe d’appartenance. 
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Figure 17.14 — Les processus de management des ressources humaines. 


17.9.2 Les techniques utiles pour le management des ressources 
humaines du projet 

Pour planifier les ressources humaines ( processus 9.1), c’est-a-dire pour identifier 
et decrire les roles, les responsabilites et les relations d’ autorite, on s’appuie sur 
des descriptions classiques reproduites a la figure 17.15 : organigramme hierar- 
ch ique de la repartition d’encadrement de l’autorite dans l’equipe de projet, 
matrice d’affectation des responsabilites croisant les differents acteurs et les 
differentes activites (etpouvant dans le cas d’une grille dite RACI, faire apparai- 
tre a l’intersection le type d’ intervention sur l’activite : Responsabilite d’accom- 
plissement, Autorite pour prendre des decisions, Consultation sur les decisions, 
Information transmise a l’acteur sur les decisions), et description du poste des 
membres de l’equipe de projet. 



Figure 17.15 — Les outils de planification des ressources humaines 
( d'apres Guide du PMBOK, figure 9.4). 

Sur un projet necessitant de nombreuses ressources, on peut utiliser un histo- 
gramme pour representer, par type de profil, les besoins (nombre de jours-personne) 
sur la duree du projet, periode par periode. 
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Pour former l’equipe de projet ( processus 9.2), on s’appuie sur les principes 
d’organisation du travail tels que ceux developpes au paragraphe 5.1, notamment 
les criteres de composition de l’equipe et les formes de coordination a privilegier. 

Le developpement de l’equipe de projet ( processus 9.3 ) conduit a mettre en 
oeuvre des actions qui s’inspirent des theories de la motivation (recompenses, 
formation, salle commune, etc.) presentees au paragraphe 5.3, notamment une 
utilisation judicieuse des styles de management. 

La direction de l’equipe de projet (processus 9.4) comprend une evaluation 
des performances (par exemple, a partir des suivis individuels du paragraphe 7.2.2) 
et eventuellement une gestion des conflits (paragraphe 5.3.5). 


17.10 LE MANAGEMENT DES COMMUNICATIONS DU PROJET 

17.10.1 Les processus du management des communications du projet 

L’objectif commun de ces processus est de determiner les informations a diffuser 
a chaque partie prenante, notamment sur l’avancement du projet, et de s’organi- 
ser pour qu’elles soient mises a disposition en temps voulu. 

II s’agit pour cela d’etablir un plan de gestion des communications, c’est-a- 
dire de determiner quelles informations, pour qui, quand et sous quelle forme. 
Ensuite, les elements sont rassembles et presentes dans les differents formats 
prevus. Au-dela de cette remise systematique, le chef de projet s’attache gene- 
ralement a etablir et maintenir des relations de travail satisfaisantes avec les 
acteurs du projet (rencontres, reunions...) et a resoudre avec eux les problemes 
rencontres. 

La figure 17.16 recapitule ces processus, classes par groupe d’appartenance. 


Demarrage 

Planification 

Execution 

Surveillance et maitrise 

Cloture 


10.1. Planification 
des communications 

10.2. Diffusion 
de 1’ information 

10.3. Etafilissement des 
rapports d’avancement 

10.4. Manager les parties 
prenantes 



Figure 17.16 — Les processus de management des communications. 


17.10.2 Les techniques utiles pour le management 
des communications du projet 

Pour elaborer un plan de management des communications ( processus 10.1), on 
analyse les besoins en communication a partir des elements precedemment 
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elabores (analyse des parties prenantes, organigramme du projet...)- Le choix 
d’une technologie support depend de notamment de l’urgence de l’information, 
de la duree du projet et de son environnement. 

Dans la diffusion de l’information ( processus 10.2), on utilise differents 
canaux (reunions, documents papiers ou electroniques, intranet...) pour codec- 
ter et diffuser l’information planifiee ou faisant l’objet de demandes ponctuelles. 

Pour etablir les rapports d’avancement (processus 10.3), on peut s’appuyer sur 
des indicateurs et une structure de tableau de bord predefinis (paragraphe 7.2) ou 
normalises (paragraphe 7.3). 

Dans le management des parties prenantes ( processus 10.4), on peut avoir a 
resoudre des problemes (par exemple en utilisant les strategies de resolution de 
conflit), dont on gardera eventuellement trace dans un journal de bord (exemple 
de la figure 12.23 a la fin du paragraphe 12.8) 


17.11 LE MANAGEMENT DES RISQUES DU PR01ET 

17*11*1 Les processus du manasement des risques du projet 

L’objectif commun de ces processus est de reduire la probability et les conse- 
quences d’evenements defavorables au projet et d’eventuellement augmenter 
celles qui lui sont favorables. II s’agit, pour ce faire, d’identifier les risques du 
projet, de les analyser et, si besoin est, d’elaborer des parades, ce qui est consigne 
dans un plan de management des risques. Ensuite, les mesures prevues sont, le 
cas echeant, appliquees et un suivi regulier de l’etat des risques est mis en place. 

La figure 17.17 recapitule ces processus, classes par groupe d’appartenance. 
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Figure 16.17 — Les processus de manasement des risques. 
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17.11,2 Les techniques utiles pour le management des risques 
du projet 

L’elaboration du plan de management des risques (processus 11.1), qui vient 
enrichir le plan de management de projet, permet, a travers des reunions de 
l’equipe de projet elargie eventuellement a d’autres parties prenantes, de se 
mettre d’ accord sur les methodes d’analyse des risques a utiliser ainsi que sur les 
niveaux qui seront consideres comme critiques. En effet, il y a toujours un arbi- 
trage a faire entre prise de risque et cout de prevention des risques, et la sensibi- 
lite aux risques differe d’une organisation a l’autre. II s’agit de definir et attribuer 
des roles et responsabilites de gestion des risques, ainsi que la frequence d’ appli- 
cation des analyses et operations de surveillance. 

Les trois processus suivants (identification et analyse) correspondent a 
l’approche generalisee que nous avons decrite au paragraphe 6.2.2 : elaborer une 
liste tres large de risques possibles et restreindre progressivement sur les quelques 
risques que Ton voudra controler. L’ identification des risques ( processus 11.2) 
s’appuie sur differentes techniques presentees au paragraphe 6.2.2. 

On peut aussi s’appuyer sur differentes typologies, comme celle proposee par 
Euromethode ou par PAFITEP pour les projets systeme d’information (paragra- 
phe 6.2.3), ou plus generale comme celle du PMBOK (figure 17.18). On peut 
aussi cibler sur les sources majeures, comme nous l’avons montre avec la grille 
d’analyse des risques (paragraphe 6.2.4). 


Projet 
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1 Estimation | 

1 Technologie | 

1 Reglementations | 
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1 Complexity 1 
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1 Maitrise | 
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1 Priorites | 
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Figure 17.18 — Typologie structure des risques (Source : PMBOK, 2004). 
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L’ analyse qualitative des risques (processus 11.3 ) vise a evaluer l’importance 
de chacun des risques precedemment identifies pour ne retenir que les plus 
importants. On peut ainsi analyser l’impact d’un risque sur les objectifs (cout, 
delai, contenu, qualite) ou classer les risques par probability d’occurrence et 
impact (paragraphe 6.2.3). Dans le cas d’un projet systeme d’information, on 
peut utiliser les criteres et metriques d’une grille d’analyse des risques, comme 
presente au paragraphe 6.2.4. 

L’analyse quantitative des risques (processus 11.4), qui consiste a effectuer 
1’ analyse chiffree des effets des risques identifies, n’est pas utilisee pour les projets 
systemes d’information ou l’incertitude est en general trap elevee. Elle recourt a 
des techniques appliquees a l’analyse de processus repetitifs pour lesquels on peut 
etablir des distributions de probability. Ainsi, une analyse de sensibilite qui aide 
a classer les facteurs ayant un impact potentiel sur un effet redoute. Par exemple, 
le diagramme en tomade presente a la figure 17.19 montre l’influence (positive 
ou negative) de differents facteurs sur le respect des delais. 


Facteurs 

Cooperation client 
Qualite sous-traitant 
Productivity developpeurs 
Qualite concepteurs 
Demenagement 
Utilisation intranet 
Utilisation AGL 


bon mauvais 



Figure 17.19 — Diagramme en tomade pour classer les facteurs de risque. 


On pourrait egalement, pour quantifier la comparaison entre deux scenarios 
presentant tous deux des risques, utiliser la technique de la Valeur monetaire 
attendue decrite au paragraphe 7.4. 

La planification des reponses aux risques retenus au terme de l’analyse 
(processus 11.5 ) vise a elaborer des options et des actions pour reduire les menaces 
et ameliorer les opportunity favorables au projet. Les differents types de reponse 
ont ete presentes au paragraphe 6.4.1. Pour les projets de systeme d’information, 
on parle de strategic de projet prenant en compte de faqon integree l’ensemble 
des risques majeurs identifies, comme decrit au paragraphe 6.4.2. 

La surveillance et maitrise des risques (processus 11.6 ) consistent a reanalyser 
periodiquement la situation des risques et les actions entreprises. On s’appuie 
pour cela sur les reunions de revue de projet et l’analyse des ecarts et tendances 
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(par exemple, ceux donnes par les indicateurs de la valeur acquise dans le suivi 
des couts et des delais). On peut egalement faire un audit, c’est-a-dire une revue 
ponctuelle et structuree, par exemple selon le schema du Standish Group 
presente au paragraphe 6.4.3. 


17.12 LE MANAGEMENT DES APPROVISIONNEMENTS DU PROJET 

1 7. 12. 1 Les processus du management des approvisionnements 
du projet 

L’objectif commun de ces processus est d’acquerir de fagon efficace et efficiente 
des biens ou services foumis par une entreprise exterieure. 

Pour cela, on commence par determiner ce qu’il est necessaire ou preferable 
d’acheter ou sous-traiter et a quel moment dans le projet : cela donne lieu a un 
plan de management des approvisionnements, qui vient s’inscrire dans le plan 
de management de projet. La nature des contrats est ensuite etudiee (par exem- 
pie regie ou forfait). Aux moments planifies, il s’agit de lancer l’appel d’offres 
correspondant et de selectionner le foumisseur. Apres contractualisation, 
l’execution du contrat fait l’objet d’un suivi de realisation et d’une gestion des 
paiements. En fin de phase (ou fin de projet), le contrat est clos officiellement 
apres reglement des points en suspens. 

La figure 17.20 recapitule ces processus, classes par groupe d’appartenance. 
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Figure 17.20 — Les processus de management des approvisionnements. 


17.12.2 Les techniques utiles pour le management 
des approvisionnements du projet 

Pour planifier les approvisionnements du projet (processus 12.1), on peut recourir a 
la technique de l’arbre de decision et de la valeur monetaire attendue si Ton hesite 
devant l’altemative « faire ou acheter ? ». Le type de contrat est egalement discute 
et selectionne. Ces deux aspects sont presentes au paragraphe 7.4.1. 
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Lors de la planification des contrats ( processus 12.2), on recourt souvent a des 
contrats-types et on prepare les criteres devaluation des reponses aux appels 
d’offres en s’appuyant sur des listes de criteres que Ton adapte et complete. 

Pour obtenir des offres ou des propositions ( processus 12.3), on fait connaitre 
son besoin de fagon publique ou aupres de foumisseurs preselectionnes (par 
exemple, uniquement des fournisseurs certifies IS09000), et on organise parfois 
une reunion pour les foumisseurs interesses afin de clarifier le besoin et donner a 
tous le meme niveau d’information. 

Le choix d’un foumisseur (processus 12.4) est souvent un processus a deux 
temps : on elabore d’abord une liste restreinte, on effectue ensuite une evaluation 
detaillee des deux ou trois restants. On fait parfois appel des experts indepen- 
dants, notamment pour juger de la pertinence du cout annonce, et on s’appuie 
en general sur une grille multicritere, comme celle presentee au paragraphe 7.5.1. 

L’ administration du contrat (processus 12.5) consiste a gerer les relations avec 
le foumisseur, et tout particulierement de suivre l’avancement afin de pouvoir 
integrer les informations dans le tableau general d’avancement du projet, y 
compris les previsions d’achevement. Sur des sous-traitances importantes, des 
revues du travail accompli, voire des audits, peuvent etre effectues. 

Ainsi s’acheve cette mise en correspondance entre les processus de manage- 
ment de projet, tels que structures par le Guide PMBOK, et les principes et tech- 
niques applicables aux projets de systeme d’information. La preparation de la 
certification passe ensuite par une prise de connaissance approfondie du Guide 
de reference, et surtout son application dans des questions de mise en situation. 
Quelques exemples de questions sont donnes en annexe D. 
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Methodes agiles 
et referentiel PMBOK 


Les methodes agiles se sont demarquees des approches plus classiques de gestion 
d’un projet informatique, en particulier en ce qui conceme le cycle de develop- 
pement (cf. § 2.8) et la place des utilisateurs (cf. § 5.5.2). La radicalite des 
auteurs du courant agile explique peut-etre l’utilisation limitee de telles appro- 
ches. Nous avons defendu, tout au long de cet ouvrage, une idee centrale dans le 
management des projets, qui est celle de 1’ adequation. Loin de defendre une 
ligne de conduite unique, nous avons cherche a donner au lecteur les moyens 
d’une approche adaptee a chaque situation de projet. C’est pourquoi nous propo- 
sons, dans ce chapitre final, de replacer de la conduite d’un projet en mode agile 
dans la perspective du PMBOK. 


18.1 METHODES AGILES ET LOGIQUE DU PMBOK 


Examinons d’abord la compatibility entre une approche agile et la logique 
fondamentale du PMBOK. 

La distinction entre produit et projet, avec les responsabilites specifiques du 
client et du foumisseur, est le premier principe. La determination du contenu 
du produit par le client est d’autant plus respectee que les specifications evoluent 
a sa seule demande. Lorsque des arbitrages doivent etre faits, lorsqu’une priorite 
doit etre etablie, seuls les utilisateurs peuvent en decider. Pour ce qui est du 
contenu du projet, la planification des iterations de livraison est souvent menee 
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en cooperation entre le client, le chef de projet et son equipe. Cette participa- 
tion n’enleve pas la responsabilite du maitre d’oeuvre. 

Le principe du cycle de vie, c’est-a-dire d’un decoupage en phases, est tout a 
fait respecte, et l’identification progressive des phases est admise par le PMBOK 
qui parle de « planification par vagues ». 

L’idee que les groupes de processus s’appliquent a chacune des phases est tout 
a fait respectee si Ton considere les iterations de livraison : Demarrage et Cloture 
sont bien executes une seule fois, alors Ton a plusieurs cycles de Planification - 
Execution - Surveillance et Maitrise. Selon la methode, chacune des iterations 
de developpement peut egalement respecter l’execution de processus des cinq 
groupes, c’est-a-dire inclure des activites de demarrage et de cloture. 

Examinons maintenant comment les methodes agiles par rapport aux difife- 
rents domaines de connaissances. 

1 8.2 METHODES AGILES ET MANAGEMENT DU CONTENU DU PROJET 

Si l’objectif de ce domaine de connaissance est de « s’assurer que le projet 
contient tout le travail requis, et uniquement celui-ci, pour assurer la bonne fin 
du projet », on peut considerer que les methodes agiles s’attachent a l’atteindre, 
en recherchant les approches les plus efficientes. 

II peut toutefois y avoir des ecarts importants avec une approche classique 
dans la mesure ou les processus de planification du contenu sont fortement alle- 
ges, alors que ceux de surveillance et maitrise, bien que peu formalises, sont 
renforces. En effet, on ne cherche pas a expliciter le plus tot possible un contenu 
stable du produit, mais on accepte une definition progressive, avec de nombreux 
amenagements et une verification continue par les utilisateurs participant aux 
iterations. 


1 8.3 METHODES AGILES ET MANAGEMENT DES DELAIS DU PROJET 

Le souci du respect des engagements calendaires du projet etant une preoccupa- 
tion centrale des methodes agiles, on peut retenir que l’objectif d’« assurer la 
realisation du projet en temps voulu » est bien recherche. 

Cependant, les processus de planification different fortement d’une approche 
PMBOK, notamment en ce qui conceme les iterations de developpement. 
D’abord, les activites elementaires, si elles sont bien identifiees par l’equipe, ne 
font pas l’objet d’une planification formalisee. Chaque developpeur ou binome 
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de developpeurs est charge d’un ensemble de taches et beneficie d’une latitude 
pour les mener a bien. La sequence « estimation des ressources — estimation de 
la duree — elaboration de l’echeancier » n’est pas respectee pour deux raisons 
principales. D’une part, les objectifs delais dominent et conduisent a evaluer en 
consequence la taille du contenu du projet. D’ autre part, la capacite de produc- 
tion de l’equipe, sa « velocite », determine les livraisons possibles a chaque 
iteration. 

La technique de la timebox, ainsi que les principes de motivation et d’anima- 
tion d’equipe sont d’un apport majeur dans la maitrise de l’echeancier. Mais le 
suivi des delais s’effectue en grande partie par une communication informelle et 
une coordination personnelle (standup meetings de XP ou melees de SCRUM), 
ou avec des outils plus orientes vers la dynamisation de l’equipe ( burndown chart 
de SCRUM) que vers le reporting. 


18.4 METHODES AGILES ET MANAGEMENT DES COUTS DU PROJET 

L’objectif de respect d’un budget est globalement partage par les methodes 
agiles, dans la mesure ou les couts sont principalement lies au travail consomme. 

Toutefois, la planification est moins formalisee et la justification economique 
du travail en binome est parfois difficile a apporter. 

De meme, le suivi des couts n’entre pas dans les preoccupations majeures du 
chef de projet, qui se situe plutot dans une logique de « design to cost », c’est- 
a-dire une adaptation du perimetre fonctionnel en cas de sur-consommation. 
L’utilisation d’indicateurs de performance n’est pas mise en avant, ce qui se 
comprend pour des projets de petite taille. Soulignons, par ailleurs, que nombre 
de projets systeme d’information ne font pas, dans la pratique, l’objet d’un suivi 
des couts. 


18.5 METHODES AGILES ET MANAGEMENT DE LA QUALITE DU PROJET 


L’objectif majeur du management de la qualite est que « le projet reponde aux 
besoins pour lesquels il a ete entrepris ». De ce point de vue, les methodes agiles 
sont tout a fait conformes au PMBOK. 

Si l’on regarde le detail du domaine de connaissance, on peut considerer que 
les trois processus sont inclus, sous une forme ou une autre, dans les methodes 
agiles. 
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La qualite est planifiee, en particulier a travers des activites et des roles speci- 
fiques. La qualite attendue du produit est determinee progressivement, mais fine- 
ment, par la collaboration avec les commanditaires/utilisateurs. 

La mise en oeuvre de l’assurance qualite est integree a l’organisation du 
travail, qui comprend une surveillance de l’execution des actions visant la 
qualite. Celles-ci comprennent non seulement les tests des developpeurs, mais 
aussi le respect de principe de simplicity et la recherche d’excellence technique. 
Le partage des connaissances dans un binome ou au sein de l’equipe vise aussi a 
donner confiance dans la qualite du futur produit. 

La surveillance des livrables, par l’equipe comme par l’utilisateur conseiller, 
selon le terme de DSDM, ainsi que le principe d’effectuer une integration syste- 
matique de tout composant elementaire, des son achevement, assurent a priori 
une mise en oeuvre effective du controle qualite. 


18.6 METHODES AGUES ET MANAGEMENT DES RESSOURCES HUMAINES 
DU PROJET 

La gestion des ressources humaines est une preoccupation centrale des methodes 
agiles, et l’on peut considerer que tous les processus y figurent a un titre ou 
l’autre. 

En effet, les ressources humaines sont planifiees, avec notamment les roles 
necessaires. 

L’objectif du processus de developpement de l’equipe, qui est d’« ameliorer 
les competences et la cooperation des membres de l’equipe afin d’ ameliorer les 
performances du projet », est manifestement poursuivi par les methodes agiles 
en ce qui conceme les developpeurs, a travers les differentes dispositions dont 
nous avons parle au paragraphe 5.5. 

De meme, le processus de direction de l’equipe de projet, qui consiste a 
« suivre la performance des membres de l’equipe, effectuer des retours d’informa- 
tion, resoudre les problemes et coordonner les modifications en vue d’ameliorer 
la performance du projet », se retrouve a des degres divers dans les methodes 
agiles. Bien sur, la delegation et la participation sont des styles privileges, et 
le suivi de la performance est en general effectue de fagon non formalisee. 
Cependant, on peut considerer que l’encadrement de l’equipe y est souvent plus 
rigoureux que dans des approches classiques. C’est d’ailleurs la raison invoquee 
par le concepteur de la methode Crystal pour proposer une methode, certes 
moins efficace que XP, mais plus facile a accepter par l’equipe en termes de 
discipline imposee. 


18.7. Methodes agiles et management des communications du projet 




18.7 METHODES AGILES ET MANAGEMENT DES COMMUNICATIONS 
DU PROJET 

Les preconisations des methodes agiles semblent eloignees de celle du PMBOK 
telle qu’elle apparait a travers les quatre processus lies aux communications. 
Cependant, si l’on retient que « les processus de management des communica- 
tions du projet apportent les liens indispensables entre les gens et les informations 
necessaires a une communication reussie », on doit reconnaitre que cet objectif 
est le plus souvent atteint dans les projets agiles, et qu’il est revendique par les 
methodes. Mais les approches preconisees different, la-aussi, par le degre de 
formalisation. 

Selon le Manifeste Agile, la vraie mesure de l’avancement est la fourniture 
d’un logiciel qui fonctionne correctement. De ce fait, les tableaux d’avancement 
ne sont pas une priorite, voire meme une perte de temps. La communication 
orale et en face a face est privilegiee. 

18.8 METHODES AGILES ET MANAGEMENT DES RISQUES DU PROJET 

Nous avons developpe au § 6.5, la question des risques dans les methodes agiles 
et montre a la fois que le profil est a priori plus favorable et que le potentiel de 
reussite est plus eleve. Par consequent, l’objectif du management des risques est 
pris en compte par ces methodes. 

La reduction des risques est liee aux dispositions, ce qui explique en grande 
partie pourquoi les processus d’ analyse des risques (identification, analyse 
qualitative et quantitative) ne font pas partie des recommandations agiles. La 
surveillance et maitrise des risques s’effectue par un suivi rapproche d’une 
equipe, qui est de taille moyenne, et la proximite du client/commanditaire evite 
les risques dus a une mauvaise communication. 

18.9 METHODES AGILES ET MANAGEMENT DES APPROVISIONNEMENTS 
DU PROJET 

Les methodes agiles evoquent peu les questions de sous-traitance du projet. II est 
toujours implicite que les utilisateurs doivent etre geographiquement proches, et 
que les estimations et la planification sont revues a chaque iteration. 

Certaines experiences font toutefois etat de l’utilisation d’une approche 
iterative sous-traitee a distance. Dans de tels cas, l’integration est placee sous 
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le controle du client, et les specifications font l’objet d’une formalisation plus 
poussee. 

18.10 METHODES AGUES ET MANAGEMENT DE L'lNTEGRATION DU PROJET 

Le management de P integration du projet est aborde de fagon differente par les 
methodes agiles sur deux points principaux : le plan de management de projet, 
ainsi que la surveillance et maitrise. 

Comme on l’a deja evoque, notamment a propos du contenu du projet, la 
planification du projet est non seulement moins formalisee, mais elle est aussi 
progressive. Par consequent, ce qui tient lieu de plan de management de projet 
est susceptible devolutions au gre du deroulement et pas forcement a des 
moments planifies, tels que les fins de phase. 

La surveillance et la maitrise du projet reposent davantage sur les personnes 
que sur des procedures et des documents. Les modifications sont maitrisees a 
travers la negociation avec les clients/utilisateurs et le respect commun d’un 
objectif delai. 

Pour les petits projets, il est generalement admis que les personnes peuvent 
suppleer a un deficit de formalisation. Mais depuis quelques annees, praticiens et 
methodologues ont cherche a combiner methodes agiles et approches de mana- 
gement plus structurees 1 . L’objectif est en particulier d’introduire une certaine 
agilite dans les grands projets pour faire face de fagon plus reactive aux aleas, et 
beneficier d’une maitrise accrue des delais et de la qualite. 

Plusieurs questions ont ete soulevees. 

Quel est le niveau de planification requis ? Jusqu’ou faut-il aller dans la defi- 
nition du systeme global, c’est-a-dire son architecture fonctionnelle ? 

Peut-on faire fonctionner une equipe de plus de dix developpeurs ? Comment 
coordonner plusieurs equipes travaillant en parallele ? 

Peut-on utiliser des methodes agiles pour des projets dont tous les acteurs ne 
sont pas situes sur le meme lieu ? 

Les approches agiles sont-elles aussi adaptees lorsque la composante parame- 
trage ou integration de systemes est plus importante que le developpement ? 

Des reponses definitives n’ont pas encore ete apportees, mais plusieurs pistes 
se dessinent. 


1. Voir par exemple D. J. Reifer, F. Maurer et H. Erdogmus, « Scaling agile methodes », IEEE 
Software, 0740-7459/03, 2003. 
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Une observation fine des pratiques laisse penser que les approches tradition- 
nelles, sans revendiquer un label agile, integrent une certaine souplesse et que la 
dichotomie agile/non agile ne serait pas si marquee 1 . 

Par exemple, la cooperation et la communication en face a face occupent 
souvent une place centrale, en particulier dans les petites equipes. Lorsque des 
changements sont juges importants, les parties prenantes n’hesitent pas a inte- 
grer des changements dans les specifications. 

On peut done considerer que la culture de l’agilite se repand, et que l’utilisa- 
tion ponctuelle de certaines techniques depasse le perimetre des projets agiles. 

Certaines recommandations ont ete emises concemant les grands projets 2 . 
On peut notamment relever deux principes, deja evoques dans le chapitre 6 sur 
la gestion des risques. 

D’une part, avant de s’engager dans une demarche d’iterations accelerees et 
participatives, il importe d’ avoir solidement construit les fondations du futur 
systeme. Une definition des processus metiers concernes par le projet et une 
representation conceptuelle des informations peuvent etre de bons outils pour 
construire une vision claire du contenu du produit. 

D’ autre part, une analyse des caracteristiques du projet, y compris son envi- 
ronnement technique et les parties prenantes, semble etre hautement necessaire 
pour decider du degre d’agilite a introduire dans le projet. 


1. Voir par exemple C. Hansson, Y. Dittrich, B. Gustafsson et S. Zamak, « How agile are indus- 
trial software development practices ? », The Journal of Systems and Software, 79, 1295-1311, 
2006. 

2. Voir par exemple B. Boehm et R. Turner, « Management challenges to implement agile pro- 
cesses in traditional development organizations », IEEE Software, 0740-7459, 2005. 



Conclusion 


Le champ du management d’un projet systeme d’ information est large. La mise 
en oeuvre des principes et techniques appelle quelques remarques de cloture. 

La prise en main d’un projet commence par un examen de ses caracteristiques 
et un diagnostic des risques. Le decoupage structurel necessite une connaissance 
du domaine. Le decoupage temporel est choisi parmi les differents modeles exis- 
tants en fonction des risques. Cette double demarche debouche sur la mise en 
place d’une strategic adaptee. 

Les techniques d! estimation des charges ont des degres de precision divers. Elies 
s’appuient en grande partie sur une base de references, dont il faut encourager le 
developpement dans toutes les entreprises : l’estimation des charges est indisso- 
ciable de la capitalisation du savoir-faire. La plupart des methodes conduisent a 
expliciter l’idee que Ton se fait du projet, done a justifier l’estimation. Elies 
permettent les comparaisons a posteriori favorisant l’apprentissage. 

Les techniques de planification sont beaucoup plus precises que les techniques 
d’estimation. Cependant, il ne faut pas oublier que les calculs se font sur un 
decoupage propose et sur des durees estimees. Les contraintes d’ordonnance- 
ment sont elles aussi a determiner. L’ important dans un travail de planification 
est de pouvoir eventuellement ajuster le decoupage en taches ou modifier des 
contraintes d’ordonnancement. Par ailleurs, il importe de bien separer une 
planification faisant apparaitre les contraintes bees aux taches et un planning 
etabli en prenant en compte la disponibilite des ressources. 

L’ organisation du projet est un point delicat, qui influence fortement sa dyna- 
mique. Il faut etre particulierement attentif a trois points. La constitution d’une 
equipe doit faire partager la responsabilite d’atteinte des objectifs. La participation 
des utilisateurs doit etre appropriee aux caracteristiques du projet : e’est pourquoi 
elle se decide souvent a l’etablissement du plan de management de projet. Sa mise 
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en oeuvre ne doit pas etre sous-estimee. Les moyens de coordination doivent etre 
adaptes a la taille de l’equipe et au volume d’informations partagees. Les dispositifs 
formalises de coordination sont encore trap souvent negliges. 

Le pilotage du projet se fait au quotidien. Le chef du projet doit etre en perma- 
nence a proximite (reelle ou virtuelle) de l’equipe de production. II doit etre 
informe de tout evenement pouvant avoir des consequences sur le deroulement 
du projet. Sa rapidite de reaction face a des chifffes inquietants du tableau de 
bord conditionne la precision de ces chiffres : en effet les membres de l’equipe 
de projet y porteront une attention d’autant plus grande qu’ils en pergoivent la 
necessite. En ce qui conceme les actions de pilotage, nous avons choisi, dans 
l’exemple presente au chapitre 12, une affectation du chef de projet lui-meme a 
des taches de production pour faire face a une defaillance. Cette reponse ne 
presente aucun caractere obligatoire et ne se rencontre guere que sur les petits 
projets. En revanche, le chef de projet doit pouvoir suivre de pres toute la 
production. Par ailleurs, dans la prise de decision concemant l’equipe comme 
dans la gestion d’aleas pouvant conduire a des oppositions avec des tiers, il s’agit 
pour le chef de projet de choisir le mode de management adequat ou la strategic 
de resolution de conflit appropriee. 

La qualite est une preoccupation transversale au projet. Elle comporte une 
dimension organisationnelle, notamment dans la clarification des procedures et 
l’explicitation des roles. Elle a egalement un caractere relationnel, puisqu’en 
dernier ressort seul le client jugera de la qualite du produit. 

La capitalisation du savoir-faire est en developpement dans la plupart des entre- 
prises, dans la perspective elargie du knowledge management. Elle necessite un 
dispositif de memorisation et permet ensuite l’apprentissage collectif. Nous 
avons vu qu’elle repose sur l’estimation des charges. 

Le management d’un projet systeme d’information met en oeuvre differentes 
qualites dont le developpement est accelere — si ce n’est conditionne, nombre 
de cas malheureux nous le prouvent — par l’usage de principes et de techniques 
robustes. 


Annexe A 


Les outils de la gestion 
de projet 


La liste ci-dessous est donnee a titre indicatif, pour illustrer les types de logiciels 
pouvant apporter une aide a la gestion de projet, en liaison avec les techniques 
presentees dans cet ouvrage. Elle n’a aucune pretention a l’exhaustivite. 


A.1 OUTILS DESTINATION DES CHARGES 

Estimacs, distribue par Computer Associates, s’appuie sur une vingtaine de ques- 
tions touchant a l’organisation et aux caracteristiques du projet. II fonctionne 
ensuite de fagon fermee. 

Winelys, distribue par Oresys Lysys, est egalement une boite noire basee sur 
une description exteme du projet, proche de celle des points fonctionnels, ainsi 
que sur une repartition proportionnelle du cycle qui peut etre personnalisee. 

CA'FPXpert, egalement de Computer Associates, et Function Point Workbench, 
de Software Productivity Research Inc., sont bases sur la methode des points 
de fonction. 

ESTIMATE Professional, de Software Productivity Center, s’appuie sur le 
modele COCOMO II. 
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A.2 OUTILS DE PLANIFICATION ET DE SUIVI 

II existe un grand nombre de logiciels permettant de planifier et suivre les 
projets. Citons notamment Project de Microsoft — dont nous avons donne un 
exemple au chapitre 15 — et PMW ( Projet Manager Workbench) de Applied 
Business Technology Corp. 

La plupart offrent les fonctions suivantes : 

• saisie du decoupage d’un projet a plusieurs niveaux, avec indication des 
durees et des liens entre les taches ; 

• elaboration automatique du graphe des antecedents, avec calcul des para- 
metres cles et reperage du chemin critique ; 

• saisie de 1’ affectation des ressources aux taches ; 

• personnalisation du calendrier de reference (jours feries) ; 

• elaboration automatique du diagramme de Gantt ; 

• saisie des couts par categorie : couts fixes ou couts variables lies a une 
duree ou une quantite consommee, couts standard et couts reels ; 

• calcul automatique des couts a differents niveaux : projet, tache, ressource, 

• saisie periodique des temps passes et des restes a faire ; 

• comparaison automatique entre le planifie et le realise ; 

• analyse du projet (avancement, taches en retard, prevision de cout. . . ) ; 

• modification eventuelle de la planification. 

Une offre commence a apparaitre en Open Source. Citons notamment Open 
Workbench, de Niku, ou Imendio Planner, developpe par Codefactory et promu 
par le gouvemement quebecois, ou encore Gantt project. 


Annexe B 


Les facteurs correcteurs 
de la methode 
des points fondionnels 


La methode des points fonctionnels fournit des directives pour determiner 
l’influence de certaines caracteristiques du futur systeme informatique. Chaque 
tableau presente le degre d’influence, compris entre 0 et5, associe a une caracte- 
ristique particuliere. 


B.1 DEGRE ^INFLUENCE DE LA COMMUNICATION DES DONNEES 


0 

L’ application ne comporte pas de telecommunications : elle toume sur un PC 
autonome ou est principalement composee de traitements par lots. 

1 

L’ application permet la saisie ou 1’ impression a distance. 

2 

L’application permet la saisie et l’impression a distance. 

3 

L’ application contient la collecte interactive des donnees en frontal a un 
traitement par lots. 

4 

L’application utilise un seul type de protocole de communication. 

5 

L’application utilise plusieurs types de protocole de communication. 
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B.2 DEGRE ^INFLUENCE DE LA DISTRIBUTION DES DONNEES 
OU DES TRAITEMENTS 


0 

Pas de repartition. 

1 

L’ application prepare les donnees qui seront transferees pour traitement local 
par l’utilisateur final. 

2 

L’ application prepare les donnees qui seront transferees pour traitement par une 
autre composante du systeme. 

3 

Les donnees et les traitements sont repartis sur plusieurs composantes : la 
distribution des traitements et le transfert des donnees sont operationnels dans 
un seul sens. 

4 

Les donnees et les traitements sont repartis sur plusieurs composantes : la 
distribution des traitements et le transfert des donnees sont operationnels dans 
les deux sens. 

5 

Les fonctions de traitement sont executees de fagon dynamique sur la 
composante la plus appropriee du systeme. 


B.3 DEGRE D’INFLUENCE DE LA PERFORMANCE 


0 

Aucune exigence particuliere. 

1 

Des exigences ont ete specifiees mais aucune action n’est necessaire. 

2 

Le temps de reponse ou le debit est crucial aux heures de pointe. L’echeance du 
traitement est le jour ouvrable suivant. 

3 

Le temps de reponse ou le debit est crucial pendant toutes les heures ouvrables. 
L’echeance du traitement des systemes en interface n’est pas contraignante. 

4 

Les exigences demandees exigent une analyse de la performance. 

5 

Les exigences demandees exigent des outils d’ analyse de la performance. 


B.4. Degre d'influence de I'intensite d’utilisation de la configuration materielle 


0 


B.4 DEGRE D'INFLUENCE DE L’INTENSITE D’UTILISATION 
DE LA CONFIGURATION MATERIELLE 


0 

Les installations ne sont pas tres utilisees. 

1 

Des limites existent, mais aucune action n’est necessaire. 

2 

Quelques considerations de securite ou de synchronisation doivent etre prises 
en consideration. 

3 

Des contraintes particulieres pour certains processeurs doivent etre prises en 
compte pour une partie de 1’ application. 

4 

Les limitations de fonctionnement imposent des contraintes particulieres a 
l’utilisation de l’unite centrale ou des processeurs dedies. 

5 

Outre les limitations des materiels, la distribution des composants impose des 
contraintes particulieres a 1’ application. 


B.5 DEGRE D'INFLUENCE DU TAUX DE TRANSACTION 


0 

Aucune periode de pointe. 

1 

Une periode de pointe est prevue : mensuelle, trimestrielle ou annuelle. 

2 

Une periode de pointe est prevue : hebdomadaire. 

3 

Une periode de pointe est prevue : quotidienne. 

4 

Les taux de transaction ou les exigences du contrat de service necessitent une 
analyse de la performance. 

5 

Les taux de transaction ou les exigences du contrat de service necessitent des 
outils d’ analyse de la performance. 


B,6 DEGRE D'INFLUENCE DE LA SAISIE INTERACTIVE 


0 

Toutes les transactions sont traitees par lots. 

1 

De 1 a 7 % des transactions sont des saisies de donnees interactives. 

2 

De 8 a 15 % des transactions sont des saisies de donnees interactives. 

3 

De 16 a 23 % des transactions sont des saisies de donnees interactives. 

4 

De 24 a 30 % des transactions sont des saisies de donnees interactives. 

5 

Plus de 30 % des transactions sont des saisies de donnees interactives. 
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B.7 DEGRE DINFLUENCE DE LA CONVIVIALITE 

La convivialite peut etre assuree par differentes fonctions : menu, navigation 
facile entre les ecrans (touches de fonctions, debranchements...), aide en ligne, 
deplacement automatique du curseur, defilement de l’ecran, selection des 
donnees a l’ecran avec le curseur, utilisation des formats particuliers (couleur, 
surbrillance...), interface pour souris, fenetres deroulantes... Le multilinguisme 
de l’application est equivalent a quatre (pour deux langues) ou six fonctions 
(plus de deux langues) de convivialite. 


0 

Aucune fonction de convivialite. 

1 

Une a trois fonctions. 

2 

Quatre ou six fonctions. 

3 

Plus de six fonctions. 

4 

Plus de six fonctions et des exigences elevees d’efficacite de l’utilisateur final 
demandant une conception specifique (par exemple : minimiser l’utilisation des 
touches). 

5 

Plus de six fonctions et des exigences d’efficacite de l’utilisateur final demandant 
l’utilisation de traitements speciaux pour demontrer l’atteinte des objectifs. 


B.8 DEGRE D INFLUENCE DE LA MISE A JOUR EN TEMPS REEL DES GDI 


0 

Aucune. 

1 

Un a trois GDI, avec un faible volume et une restauration facile. 

2 

Quatre GDI, avec un faible volume et une restauration facile. 

3 

Tous les principaux GDI. 

4 

Tous les principaux GDI, avec une protection specifique contre la perte. 

5 

Tous les principaux GDI, avec une protection specifique contre la perte, des 
volumes importants et des procedures de restauration automatisees. 


B.9 DEGRE D INFLUENCE DE LA COMPLEXITY DES TRAITEMENTS 

Plusieurs types de traitements peuvent etre complexes : controle, traitement logi- 
que, algorithme, traitement des interruptions, traitement d’entrees/sorties multiples. 


B. 10. Degre d’influence de la reutilisation 




0 

Aucun traitement complexe. 

1 

Un type de traitement complexe. 

2 

Deux types de traitement complexe. 

3 

Trois types de traitement complexe. 

4 

Quatre types de traitement complexe. 

5 

Tous les types de traitement complexe. 


B.10 DEGRE D’INFLUENCE DE LA REUTILISATION 


0 

Aucune reutilisation. 

1 

L’ application integre des modules reutilisables. 

2 

Moins de 10 % des modules sont congus multi-utilisation. 

3 

Plus de 10 % des modules sont con$us multi-utilisation. 

4 

L’application a ete congue multi-utilisation. L’utilisateur peut personnaliser le 
code source. 

5 

L’application a ete con$ue multi-utilisation. La personnalisation est parametree. 


B.1 1 DEGRE D’INFLUENCE DE LA FACILITE D’INSTALLATION 


0 

Aucune exigence particuliere. 

1 

Un reglage special est necessaire. 

2 

Des exigences de conversion et d’installation sont specifiees. 

3 

Des exigences de conversion et d’installation sont specifiees et l’impact de la 
conversion sur le projet est important. 

4 

Les exigences specifiees comprennent la fourniture d’outils automatises de 
conversion et d’installation. 

5 

Les exigences specifiees comprennent la fourniture d’outils automatises de 
conversion et d’installation et l’impact de la conversion sur le projet est 
important. 
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B.12 DEGRE DINFLUENCE DE LA FACILITE D’EXPLOITATION 

La facilite d’exploitation se mesure en points. Elle peut comprendre : des proce- 
dures de demarrage, de sauvegarde et de restauration avec intervention manuelle 
(un point) ou sans (deux points), une reduction du montage des bandes (un 
point), une reduction des taches de manipulation du papier (un point). 


0 

Aucune exigence particuliere. 

1 

Un point. 

2 

Deux points. 

3 

Trois points. 

4 

Quatre points. 

5 

L’application doit fonctionner de fagon autonome : l’operateur n’intervient que 
pour demarrer et arreter 1’ application. 


B.13 DEGRE D INFLUENCE DE LA PORTABILITY 


0 

Aucune exigence particuliere. 

1 

Portability dans des environnements materiel et logiciel identiques. 

2 

Portability dans des environnements materiel et logiciel similaires. 

3 

Portability dans des environnements materiel et logiciel differents. 

4 

Des plans de maintenance multisite sont demandes pour des environnements 
materiel et logiciel identiques ou similaires. 

5 

Des plans de maintenance multisite sont demandes pour des environnements 
materiel et logiciel differents. 


B.14 DEGRE D INFLUENCE DE LA FACILITE D ADAPTATION 

La facilite d’adaptation se mesure en points. Elle permet a l’utilisateur de modi- 
fier les sorties obtenues ou les parametres de l’application. Elle comprend les 
caracteristiques suivantes : possibility de modifier facilement des demandes 
d’interrogation ou d’edition simples (un point), moyennes (deux points) ou 
complexes (trois points) ; mise a jour des parametres utilisateur (par exemple : 


B. 14. Degre d’influence de la facilite d'adaptation 



valeur d’un taux de TVA) par traitement interactif avec prise en compte le 
prochain jour ouvrable (un point) ou immediatement (deux points). 


0 

Aucune exigence particuliere. 

1 

Un point. 

2 

Deux points. 

3 

Trois points. 

4 

Quatre points. 

5 

Cinq points. 
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Grille d’analyse 
des risques 


La grille proposee permet de determiner le degre de risque de chaque facteur. 

Le degre de risque du facteur est calcule de la fagon suivante : 

Degre de risque d’un facteur 

Somme (degre de chaque critere * ponderation) / Somme des ponderations 

Souvent, on prend la moyenne arithmetique de la valeur des criteres corres- 
pond ants. Parfois, une ponderation peut etre definie pour majorer l’importance du 
critere dans le facteur etudie. Par exemple pour le facteur instability de l’equipe 
de projet le critere image du projet (ponderation : 2) peut etre apprecie comme 
deux fois plus important que le critere technique attrayant (ponderation : 1). 

Par ailleurs un critere peut parfois etre qualifie de dominant. Dans ce cas le 
degre calcule du facteur ne peut etre inferieur au degre de ce critere. Par exemple 
si le degre du critere duree du projet du facteur taille du projet est de 3 le degre 
du facteur ne pourra etre inferieur a 3. 

Les criteres et les metriques sont donnes ci-dessous. 
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Criteres pour : Taille du projet 

Degre 

Metrique 


Duree du projet 

1 

=< 6 mois 


2 

=<18 mois 


3 

=< 30 mois 


4 

> 30 mois 


Charge du projet 

1 

=< 20 mois/personne 


2 

=< 120 mois/personne 


3 

=< 300 mois/personne 


4 

> 300 mois/personne 


Couverture fonctionnelle 

1 

=< 2 processus 


2 

=< 6 processus 


3 

=<10 processus 


4 

> 10 processus 


Criteres pour : Difficulty technique 

Degre 

Metrique 


Experience de l’entreprise 
sur 1’ architecture ciblee 

1 

2 projets 


2 

1 projet 


3 

Projet(s) technologie 
voisine 


4 

Aucune experience 


Experience de l’entreprise 
sur le langage de programmation 

1 

2 projets 


2 

1 projet 


3 

Projet(s) technologie 
voisine 


4 

Aucune experience 


Experience de l’entreprise sur le SGBD 

1 

2 projets 


2 

1 projet 


3 

Projet(s) technologie 
voisine 


4 

Aucune experience 


Experience du marche 
sur 1’ architecture ciblee 

1 

Plus de 200 references 


2 

Plus de 100 references 


3 

Plus de 50 references 


4 

Moins de 10 references 
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Criteres pour : Difficulty technique (suite) 

Degre 

Metrique 


Experience du marche 
sur le langage de programmation 

1 

Plus de 200 references 


2 

Plus de 100 references 


3 

Plus de 50 references 


4 

Moins de 10 references 


Experience du marche sur le SGBD 

1 

Plus de 200 references 


2 

Plus de 100 references 


3 

Plus de 50 references 


4 

Moins de 10 references 


Contrainte de performance 
(par rapport aux contraintes volumetriques 
hahituelles de l’entreprise) 

1 

Pas de contrainte 


2 

Normale 


3 

Elevee 


4 

Tres elevee 


Place et responsabilite de la Direction 
informatique 

1 

La Direction informa- 
tique assure la respon- 
sabilite technique 


2 

La Direction informa- 
tique anime la respon- 
sabilite technique 


3 

Pas de Direction 
informatique. 

La responsabilite techni- 
que est sous-traitee. 


4 

Pas de Direction 
informatique. 

La responsabilite techni- 
que n’est pas assuree. 


Criteres pour : Degre d’integration 

Degre 

Metrique 


Nombre de flux (type) avec des applica- 
tions connexes 

1 

=< 1 


2 

=< 10 


3 

=< 20 


4 

> 20 


Nombre d’ applications connexes 
en chantier 

1 

Aucune 


2 

= 1 


3 

= 2 


4 

> 2 
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Criteres pour : 

Configuration organisationnelle 

Degre 

Metrique 


Nombre de directions assurant la maitrise 
d’ouvrage (MO A) 

1 

= 1 


2 

= 2 


3 

= 3 


4 

> 3 


Existence et implication d’un promoteur 
(parmi les MO A) 

1 

Nomme, implique, legi- 
time 


2 

Nomme, implique 


3 

Nomme 


4 

Pas de promoteur 


Perennite du promoteur 
(s’il existe) 

1 

Couvrira tout le projet 


2 

Pourra etre relaye avec 
la meme ligne (par une 
emanation de la DG) 


3 

Pourra etre relaye avec 
une ligne differente 


4 

Pourra ne pas etre relaye 


Appui de la Direction generale 
(DG) 

1 

Suivi par la DG 


2 

DG informee 


3 

Pas d’ implication de la 
DG, mais une seule 
MOA 


4 

Pas d’ implication de la 
DG et plusieurs MOA 


Criteres pour : Changement 

Degre 

Metrique 


Degre d’ evolution organisationnelle 
(pour les utilisateurs) 

1 

Pas d’ecart 


2 

Ecart faible 


3 

Ecart moyen 


4 

Ecart fort 


Degre devolution fonctionnelle 
(pour les utilisateurs) 

1 

Pas d’ecart 


2 

Ecart faible 


3 

Ecart moyen 


4 

Ecart fort 



C. Grille d'analyse des 


El 


Criteres pour : Changement (suite) 

Degre 

Metrique 


Degre devolution technique 
(pour les utilisateurs) 

1 

Pas d’ ecart 


2 

Ecart faible 


3 

Ecart moyen 


4 

Ecart fort 


Impact social 

1 

Aucune consequence 


2 

Reduction d’effectif 


3 

Reduction salaire 


4 

Reduction effectif et 
salaire 


Nombre de sites concemes 

1 

1 


2 

Moins de 10 


3 

Moins de 50 


4 

Plus de 50 


Criteres pour : Instability de l’equipe 

Degre 

Metrique 


Duree du projet 

1 

=< 6 mois 


2 

=<18 mois 


3 

=< 30 mois 


4 

> 30 mois 


Sous-traitance de la maitrise d’ceuvre 

1 

0% 


2 

40% 


3 

70% 


4 

100% 


Tum-over/mobilite 
dans l’entreprise 

1 

Tres faible 


2 

Faible 


3 

Moyenne 


4 

Forte 


Relation MOA - MOE 

1 

Excellente 


2 

Bonne 


3 

Moyenne 


4 

Mauvaise 


Techniques attrayantes 

1 

Tres 


2 

Normale 


3 

Peu 


4 

Pas 
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Criteres pour : 
Instability de l’equipe (suite) 

Degre 

Metrique 


Conjoncture 
(marche de l’emploi) 

1 

Difficile (pour les 
employes) 


2 

Moyenne 


3 

Favorable 


4 

Tres favorable 


Image du projet 

1 

Tres valorisante 


2 

Valorisante 


3 

Moyennement valori- 
sante 


4 

Faiblement valorisante 



Annexe D 


Exemples de questions 
pour la certification 


1 . 

Vous etes le chef d’un projet d’un nouvel intranet pour une compagnie d’ assurance. 
Bien entendu, la direction veut que votre projet rapporte beaucoup (en reduisant les 
couts de communication interne) et coute peu. Le Directeur informatique est parti- 
culierement exigeant sur les questions de securite. Les developpeurs pressentis 
souhaitent experimenter un nouvel outil de developpement. Quand vous allez travailler 
avec les differentes parties prenantes du projet, vous devriez : 

A. Repartir les parties prenantes en categories pour les identifier facilement. 

B. Etre attentif au fait que les parties prenantes peuvent avoir des attentes tres dif- 
ferentes et leur gestion est parfois delicate. 

C. Reconnaitre que les roles et responsabilites peuvent se chevaucher. 

D. Reduire les activites des parties prenantes qui peuvent avoir un effet negatif sur 
le projet. 

2. 

Quelle forme de resolution de conflit utilise-t-on lorsque l’on declare « Je ne veux 
pas traiter ce probleme maintenant » ? 

A. Compromis. 

B. Apaisement. 

C. Retrait. 

D. Cooperation. 
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3. 

Vous construisez un centre d’ exploitation informatique de 500 serveurs en Papouasie 
pour mettre en oeuvre un grand projet de e-commerce principalement en direction 
de l’Asie. Cet endroit offre des avantages economiques certains, mais le risque de 
typhon vous a conduit a prevoir un repli sur le site de Manille en cas d’inondation 
du centre. Ceci est un exemple de : 

A. Acceptation passive. 

B. Evitement. 

C. Acceptation active. 

D. Reponse conditionnelle. 

4. 

Vous venez d’etre nomme responsable d’un grand projet de telecommunication qui a 
commence depuis un an et met en jeu 25 personnes. Vous voulez savoir precisement 
qui est responsable de quoi dans ce projet. Ou pouvez-vous trouver cette information ? 

A. Diagramme hierarchique. 

B. Grille RACI. 

C. Structure de decoupage du projet. 

D. Fiche de competence. 

5. 

Vous travaillez sur un projet de site web visant les proprietaries d’animaux exoti- 
ques. Au debut, le produit a ete defini par votre client comme « un portail offrant 
des liens avec tous les sites interessants ». Puis il a ete decrit comme « un portail 
offrant des liens avec tous les sites interessants, ainsi que des informations juridi- 
ques sur le transport de ces animaux ». Ceci montre que 1’ elaboration progressive 
des specifications du produit doit etre soigneusement coordonnee avec : 

A. Les parties prenantes. 

B. Un systeme de maitrise des modifications du projet. 

C. Le plan strategique du client. 

D. Une definition precise du contenu du projet. 

6. 

Une activite a comme date de debut au plus tot le 3 avril, comme date de debut au 
plus tard le 13 avril, comme de date de fin au plus tot le 9 avril, comme date de fin au 
plus tard le 19 avril. Sa marge libre est nulle. Vous en deduisez que cette activite : 

A. est sur le chemin critique. 

B. a un retard. 

C. avance correctement. 

D. n’est pas sur le chemin critique. 

7. 

On vous demande de terminer votre projet trois jours plus tot que prevu. Quelle est 
la meilleure chose a faire ? 

A. Preparer un plan de secours. 

B. Demander a votre equipe de travailler plus vite. 

C. Reunir l’equipe et regarder les possibility de compression des delais ou de 
chevauchement des taches qui sont sur le chemin critique. 

D. Demander une ressource supplementaire. 
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8. 

Votre client vous demande de concevoir une application facile d’apprentissage. 
Vous convenez ensemble que la formation necessaire a la prise en main ne doit pas 
depasser deux heures. Ceci est avant tout un exemple de : 

A. Cycle en V. 

B. Bonne communication avec les parties prenantes. 

C. Determination d’une metrique de la qualite produit. 

D. Participation. 

9. 

Un membre de votre equipe vient de demissionner brusquement et a ete autorise a 
ne pas effectuer son preavis. Votre projet est dans une situation critique. En atten- 
dant l’arrivee d’une nouvelle ressource, vous devez reorganiser le travail et eviter 
que le moral de 1’ equipe, jusque-la tres motivee, ne baisse. Le style de leadership a 
privilegier est : 

A. Directif apres information. 

B. Consultatif. 

C. Directif, puis persuasif. 

D. Persuasif et participatif groupe. 

10. 

Vous etes responsable d’un projet robotique. Une nouvelle technologie vient d’etre 
mise sur le marche, qui va ameliorer la precision des connecteurs et reduire le tra- 
vail necessaire. On vous demande une nouvelle estimation du cout total de votre 
projet (PAA). La meilleure methode consiste a : 

A. Effectuer une analyse de la VA pour determiner l’indice de performance des 
couts. 

B. Ajouter les couts reels et le budget restant modifie d’un facteur de performance. 

C. Ajouter les couts reels et le resultat d’une nouvelle estimation pour le travail 
restant. 

D. Ajouter le budget restant a ce qui a deja ete depense. 

11. 

En vous basant sur tout un ensemble d’ estimations, vous savez que votre projet va 
probablement durer 50 jours, aupire 120 etaumieux 40 jours. Quelle valeur retenez- 
vous ? 

A. 45 jours. 

B. 70 jours. 

C. 50 jours. 

D. 60 jours. 

12. 

Pour reduire la duree de votre projet, vous decidez de confier une activite a deux 
personnes au lieu d’une seule. Cette approche tend a : 

A. Ameliorer la communication dans 1’ equipe. 

B. Augmenter les couts de coordination. 

C. Ameliorer la valeur acquise. 

D. Utiliser la marge totale. 
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13. 

Un membre de votre equipe manque d’ experience dans le langage de programma- 
tion utilise, ce qui se traduit par une faible performance. Personne d’ autre n’est dis- 
ponible dans l’equipe. Quelle est la MEILLEURE solution pour le chef de projet ? 

A. Proposer une prime de productivite. 

B. Obtenir une ressource exteme qualifiee. 

C. Obtenir une formation pour la ressource. 

D. Replanifier les taches de developpement pour les confier a quelqu’un de plus 
experiments. 

14. 

Votre projet comporte plusieurs commanditaires et vous savez que la description 
du contenu du produit est susceptible de nombreuses modifications. Que devez-vous 
faire de fagon imperative ; 

A. Mettre en place une gestion de configuration. 

B. Refuser les changements inutiles. 

C. Demander un correspondant unique parmi vos commanditaires. 

D. Prevoir des ressources additionnelles. 

15. 

Un membre de votre equipe, base a Evry, vous informe vendredi midi qu’il a com- 
mence lundi dernier la tache « Developpement de l’interface utilisateur », sur 
laquelle il a travaille toute la semaine, qu’il est convoque l’apres-midi pour une 
visite periodique de la medecine du travail a Paris et qu’il lui reste quatre jours de 
travail pour terminer cette tache que vous aviez estimee a 9 jours. Vous en deduisez 
que son avancement de la semaine est de : 

A. 4,5 jours. 

B. 5 jours. 

C. 4 jours. 

D. 5,5 jours. 


Les reponses sont les suivantes : 

• l.B : Les parties prenantes doivent etre gerees. 

• 2.C : On evite de rencontrer l’autre partie et d’aborder le probleme. 

• 3.D : Le plan est mis en oeuvre sous condition. 

• 4-B : La grille RACI est plus precise que l’organigramme hierarchique en 
ce qui conceme les responsabilites sur les activities. 

• 5.D : Le travail a faire (contenu du projet) depend des demandes exprimees 
(contenu du produit). 

• 6.D : Les dates au plus tot etant inferieures aux dates au plus tard, la marge 
to tale est positive, la tache n’est done pas sur le chemin critique. 
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• 7.C : Rajouter une ressource pour gagner trois jours n’est generalement pas 
tres efficace. La meilleure solution est de chercher a reduire la duree du 
chemin critique. 

• 8.C : On determine une fagon de mesurer 1’atteinte d’une exigence. Cette 
metrique pourra etre utilisee dans un cycle en V, mais pas necessairement. 

• 9.C : En situation de crise, il est preferable d’agir rapidement, mais sans 
oublier de communiquer. Une autre possibility aurait ete de privilegier un 
style participate, mais elle ne figurait pas dans les choix. 

• 10.C : La prevision a l’achevement inclut toujours les couts reels : compte 
tenu du changement dans la technique utilisee, il faut faire une nouvelle 
estimation. 

• 1 1 .D : On considere que la valeur la plus probable a ete ff equemment 
citee, on prend done la formule [(au pire) + (au mieux) + 4*(la plus 
probable)]/6. 

• 12.B : Diviser un travail visant un livrable unique augmente les couts de 
coordination. 

• 13. C : Pour favoriser le developpement de l’equipe, il est preferable 
d’augmenter, si possible, les competences de ses membres. 

• 14-A : La gestion de configuration permettra de suivre les evolutions dans 
la description du produit attendu. 

• 15.B : L’avancement est la difference entre deux « reste a faire » successifs, 
soit 9-4. 
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Cet ouvrage s'adresse aux responsables de systemes d'informa- 
tion et aux chefs de projets, ainsi qu'aux etudiants en informatique 
ou systeme d'information et aux eleves ingenieurs. 

Quelle est la meilleure fagon de conduire un projet systeme d'in- 
formation ? Ce livre repond a cette interrogation en analysant les 
outils et les methodes de gestion du domaine a partir des points 
cles que sont : 

- I'analyse et le decoupage d'un projet ; 

- devaluation des risques ; 

- I'estimation des charges ; 

- les techniques de planification ; 

- ['organisation du travail ; 

- la dimension humaine et relationnelle du projet ; 

- le pilotage du projet ; 

- la maTtrise et la qualite du projet. 

- les principales normalisations internationales. 

Chacun de ces points cles fait I'objet d'exemples de mise en oeuvre, 
d'exercices et d'etudes de cas detailles et explicites. La planifica- 
tion et le pilotage d'un projet sont illustres avec le progiciel MS 
Project 2003. De plus, I'ouvrage apporte une aide a la prepara- 
tion de la certification en management de projet du PMI. 

Cette sixieme edition introduit pour chaque aspect du manage- 
ment de projet une perspective particuliere sur les methodes agiles. 
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